Raspberry Pi | Aygıt Ağacı Konfigürasyonları

Raspberry Pi’nin Raspbian ve NOOBS sürümleri de dahil olmak üzere en son çekirdekleri ve firmware’i şimdi bazı kaynak tahsisi ve modül yüklemesini varsayılan olarak yönetmek için bir Cihaz Ağacı (DT) kullanıyor. Bu, sistem kaynakları için yarışan birden fazla sürücünün sorununu hafifletmek ve HAT modüllerinin otomatik olarak yapılandırılmasına izin vermek için uygulandı. 

Mevcut uygulama saf bir Cihaz Ağacı sistemi değildir – bazı platform cihazlarını oluşturan pano desteği kodu hala vardır – ancak harici arayüzler (I2C, I2S, SPI) ve bunları kullanan ses cihazlarının şimdi bir Cihaz kullanılarak başlatılması gerekir. Ağaç Blob (DTB) yükleyici tarafından çekirdeğe geçti (start.elf). 

Cihaz Ağacı’nı kullanmanın asıl etkisi, her şeyden değişmek, çekişmeleri yönetmek için modül kara listeye dayanmak ve DTB tarafından talep edilmedikçe her şeyden uzaklaşmaktır. Dış arabirimleri ve bunlara bağlanan çevre birimlerini kullanmaya devam etmek için, config.txt’inize yeni ayarlar eklemeniz gerekir. Tam detaylar Bölüm 3’te verilmiştir, ancak bunlar birkaç örnektir: 

# Uncomment some or all of these lines to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment one of these lines to enable an audio interface
#dtoverlay=hifiberry-amp
#dtoverlay=hifiberry-dac
#dtoverlay=hifiberry-dacplus
#dtoverlay=hifiberry-digi
#dtoverlay=iqaudio-dac
#dtoverlay=iqaudio-dacplus
#dtoverlay=audioinjector-wm8731-audio

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Uncomment this to override the defaults for the lirc-rpi module
#dtparam=gpio_out_pin=16
#dtparam=gpio_in_pin=17
#dtparam=gpio_in_pull=down

Aygıt Ağaçları 

Bir Cihaz Ağacı (DT), bir sistemdeki donanımın açıklamasıdır. Temel CPU adını, bellek konfigürasyonunu ve çevre birimlerini (dahili ve harici) içermelidir. Donanımı tanımlamak için bir DT kullanılmamalıdır, ancak donanım modüllerinin listelenmesi genellikle sürücü modüllerinin yüklenmesine neden olur. DT’lerin işletim sistemi açısından nötr olması gerektiğini hatırlamanıza yardımcı olur, bu nedenle Linux’a özgü herhangi bir şey muhtemelen orada olmamalıdır. 

Bir Aygıt Ağacı, donanım yapılandırmasını bir düğüm hiyerarşisi olarak temsil eder. Her düğüm özellikler ve alt düğümler içerebilir. Özellikler, dizeleri, sayıları (big-endian), isteğe bağlı bayt dizileri ve bunların herhangi bir birleşimini içerebilen bayt dizileri olarak adlandırılır. Bir dosya sistemine benzeterek, düğümler dizinlerdir ve özellikler dosyadır. Ağacın içindeki düğümlerin ve özelliklerin yerleri, ayırıcı olarak eğik çizgiler ve kökü belirtmek için tek bir eğik çizgi (/) içeren bir yol kullanılarak tanımlanabilir. 

1: Basic DTS syntax 

Aygıt Ağaçları genellikle, Aygıt Ağacı Kaynağı (DTS) olarak bilinen bir metin biçiminde yazılır ve .dts sonekine sahip dosyalarda saklanır. DTS sözdizimi, C’ye benzer; her bir satırın sonunda gruplama ve noktalı virgül için ayraçlar bulunur. DTS’nin parantezleri kapattıktan sonra noktalı virgül gerektirdiğini unutmayın: işlevler yerine C yapılarını düşünün. Derlenmiş ikili format, Düzleştirilmiş Cihaz Ağacı (FDT) veya Cihaz Ağacı Bloğu (DTB) olarak adlandırılır ve .dtb dosyalarında saklanır. 

Aşağıdaki .dts biçiminde basit bir ağaçtır: 

/dts-v1/;
/include/ "common.dtsi";

/ {
    node1 {
        a-string-property = "A string";
        a-string-list-property = "first string", "second string";
        a-byte-data-property = [0x01 0x23 0x34 0x56];
        cousin: child-node1 {
            first-child-property;
            second-child-property = <1>;
            a-string-property = "Hello, world";
        };
        child-node2 {
        };
    };
    node2 {
        an-empty-property;
        a-cell-property = <1 2 3 4>; /* each number (cell) is a uint32 */
        child-node1 {
            my-cousin = <&cousin>;
        };
    };
};

/node2 {
    another-property-for-node2;
};

Bu ağaç şunları içerir: 

Gerekli bir başlık: /dts-v1/. 

Geleneksel olarak * .dtsi adlı ve C’deki bir .h başlık dosyasına benzeyen başka bir DTS dosyasının eklenmesi – bkz. 

• tek bir kök düğümü: / 
• Alt düğümlerden birkaçı: düğüm1 ve düğüm2 
• düğüm1 için bazı çocuklar: alt düğüm1 ve alt düğüm2 
• bir etiket (kuzen) ve bu etiket kuzenine referans): bkz. aşağıdaki Etiketler ve Referanslar. 
• Ağaca dağılmış çeşitli özellikler 
• yinelenen bir düğüm (/ düğüm2) – bkz. Bir taraf / yaklaşık / aşağıda bir kenara. 

Özellikler, değerin boş olabileceği veya isteğe bağlı bir bayt akışı içerebildiği basit anahtar / değer çiftleridir. Veri tipleri veri yapısında şifrelenmemiş olsa da, bir Cihaz Ağacı kaynak dosyasında ifade edilebilecek birkaç temel veri gösterimi vardır. 

Metin dizeleri (NULL-sonlandırılmış) çift tırnak işareti ile belirtilmiştir: 

string-property = "a string";

Hücreler açılı ayraçlarla ayrılmış 32 bit işaretsiz tam sayılardır: 

cell-property = <0xbeef 123 0xabcd1234>;

İsteğe bağlı bayt verileri köşeli ayraçlarla sınırlandırılır ve onaltılık olarak girilir: 

binary-property = [01 23 45 67 89 ab cd ef];

Farklı temsillerin verileri virgül kullanılarak birleştirilebilir: 

mixed-property = "a string", [01 23 45 67], <0x12345678>;

Virgüller ayrıca dizelerin listelerini oluşturmak için kullanılır: 

string-list = "red fish", "blue fish";

1.2: An aside about /include/ 

/ İnclude / directive, C’nin #include direktifine benzer şekilde, basit metinsel içerme ile sonuçlanır, ancak Aygıt Ağacı derleyicisinin bir özelliği farklı kullanım modellerine yol açar. Düğümlerin potansiyel olarak mutlak yollarla adlandırıldığına bakıldığında, aynı düğümün bir DTS dosyasında (ve uzantılarında) iki kez görünmesi mümkündür. Bu olduğunda, düğümler ve özellikler birleştirilir, gerektiğinde araya girme ve üzerine yazma özellikleri (daha sonraki değerler daha öncekileri geçersiz kılar). 

Yukarıdaki örnekte, / node2’nin ikinci görünümü orijinaline eklenecek yeni bir özelliğe neden oluyor: 

/node2 {
    an-empty-property;
    a-cell-property = <1 2 3 4>; /* each number (cell) is a uint32 */
    another-property-for-node2;
    child-node1 {
        my-cousin = <&cousin>;
    };
};

Böylece, bir .dtsi’nin bir ağaçtaki birden fazla yerin üzerine yazması veya varsayılanları sağlaması mümkündür. 

1.3: Labels and references 

Ağacın bir kısmının bir başkasına atıfta bulunması genellikle gereklidir ve bunu yapmanın dört yolu vardır: 

• Yol dizeleri 

Yollar açıklayıcı olmalıdır, bir dosya sistemine benzetilerek – / soc / i2s @ 7e203000, BCM2835 ve BCM2836’daki I2S cihazına giden tam yoldur. Bir özellik için bir yol oluşturmak kolay olsa da (örneğin, / soc / i2s @ 7e203000 / status), standart API’lerin bunu yapmadığını unutmayın; önce bir düğüm bulursunuz, sonra o düğümün özelliklerini seçersiniz. 

• Phandles 

Bir hayalet, kendi özelliğinde bir düğüme atanan benzersiz bir 32 bit tam sayıdır. Tarihsel nedenlerden dolayı, gereksiz, eşleşen bir linux, phandle görebilirsiniz. kelepçeler 1’den başlayarak sırayla numaralandırılır; 0 geçerli bir kantar değil. Genellikle bir derleyici referansına bir tamsayı bağlamında, genellikle bir etiket şeklinde referansla karşılaştığında DT derleyicileri tarafından tahsis edilir (aşağıya bakınız). Phandles kullanan düğümlere yapılan referanslar basitçe karşılık gelen tamsayı (hücre) değerleri olarak kodlanır; Uygulama tanımlı olduğu gibi phandles olarak yorumlanması gerektiğini gösteren herhangi bir işaret yoktur. 

• Labels 

C’deki bir etiketin koddaki bir yere bir ad vermesi gibi, bir DT etiketi de hiyerarşideki bir düğüme bir ad atar. Derleyici, etiketlere referans alır ve bunları string bağlamında (& node) kullanıldığında ve tam sayı bağlamında phandles (<& node>); Orijinal etiketler derlenmiş çıktıda görünmüyor. Etiketlerin yapı içermediğine dikkat edin; Onlar sadece düz, küresel bir ad alanındaki simgelerdir. 

• Aliases 

Diğer adlar, FDT çıkışında bir dizin biçimi olarak görünmeleri dışında etiketlere benzer. / Aliases düğümünün özellikleri olarak depolanırlar, her özellik bir takma adı bir yol dizgisine eşleştirir. Diğer ad düğümü kaynakta görünmesine rağmen, yol dizeleri genellikle tam olarak yazılmak yerine etiketlere (& düğüm) referans olarak görünür. Bir yol dizesini bir düğüme çözen DT API’leri tipik olarak yolun ilk karakterine bakar, eğik çizgiyle başlamayan yolları, önce / aliases tablosunu kullanarak yola dönüştürülmesi gereken takma ad olarak ele alır. 

1.4: Aygıt Ağacı semantiği 

Bir Cihaz Ağacı oluşturmak ve bazı donanımların konfigürasyonunu yakalamak için en iyi nasıl kullanılacağından dolayı, büyük ve karmaşık bir konudur. Bazıları aşağıda listelenen birçok kaynak var, ancak bazı noktalar bu belgede belirtilmeyi hak ediyor: 

Uyumlu özellikler, donanım açıklaması ile sürücü yazılımı arasındaki bağlantıdır. Bir işletim sistemi uyumlu bir özelliğe sahip bir düğümle karşılaştığında, en iyi eşleşmeyi bulmak için aygıt sürücülerinin veritabanında arar. Linux’ta bu, sürücü etiketinin uygun şekilde etiketlenmesi ve kara listeye alınmaması şartıyla otomatik olarak yüklenmesine neden olur. 

Status özelliği bir cihazın etkin mi devre dışı mı olduğunu gösterir. Durum tamamsa, tamamsa veya yoksa, cihaz etkindir. Aksi takdirde, durum devre dışı bırakılmalıdır, böylece cihaz devre dışı bırakılır. Aygıtları durumu devre dışı olarak ayarlanmış bir .dtsi dosyasına yerleştirmek faydalı olabilir. Türetilmiş bir yapılandırma daha sonra bu .dtsi’yi içerebilir ve tamamlanması gereken cihazların durumunu ayarlayabilir. 

Bölüm 2: Aygıt Ağacı kaplamaları 

Modern bir SoC (Çip Üzerine Sistem) çok karmaşık bir cihazdır; tam bir Cihaz Ağacı, yüzlerce satır uzunluğunda olabilir. Bir adımı daha ileriye götürmek ve SoC’yi diğer bileşenlere sahip bir tahtaya yerleştirmek işleri daha da kötüleştirir. Bunu yönetilebilir kılmak için, özellikle bileşenleri paylaşan ilgili cihazlar varsa, ortak öğeleri .dtsi dosyalarına koymak, muhtemelen birden fazla .dts dosyalarına dahil etmek mantıklı olacaktır. 

Ancak Raspberry Pi gibi bir sistem, HAT gibi isteğe bağlı eklenti aksesuarlarını desteklediğinde sorun büyüyor. Sonuçta, her olası yapılandırma onu tanımlamak için bir Cihaz Ağacı gerektirir, ancak bir kez farklı temel donanımları (modeller A, B, A + ve B +) ve yalnızca bir arada bulunabilen birkaç GPIO piminin kullanımını gerektiren aygıtları ve kombinasyonlar hızla çoğalmaya başlar. 

İhtiyaç duyulan şey, kısmi bir Cihaz Ağacı kullanarak bu isteğe bağlı bileşenleri tanımlamanın ve daha sonra bir temel DT alarak ve bir dizi isteğe bağlı eleman ekleyerek tam bir ağaç oluşturabilmenin bir yoludur. Bunu yapabilirsiniz ve bu isteğe bağlı öğelere “kaplamalar” denir. 

2.1: Fragmanlar 

Bir DT yer paylaşımı, her biri bir düğümü ve alt düğümlerini hedef alan birkaç parça içerir. Konsept yeterince basit görünse de, sözdizimi ilk başta oldukça garip görünüyor: 

// Enable the i2s interface
/dts-v1/;
/plugin/;

/ {
    compatible = "brcm,bcm2708";

    fragment@0 {
        target = <&i2s>;
        __overlay__ {
            status = "okay";
        };
    };
};

Uyumlu dize, bunu BCM2835 bölümünün temel mimarisi olan BCM2708 için tanımlamaktadır. BCM2836 bölümü için uyumlu bir “brcm, bcm2709″ dizesini kullanabilirsiniz, ancak ARM CPU’larının özelliklerini hedeflemediğiniz sürece, iki mimarinin eşdeğer olması gerekir, bu nedenle “brcm, bcm2708″ e yapıştırılması makul olur. Sonra ilk (ve sadece bu durumda) parçası gelir. Fragmanlar sıfıra sırayla numaralandırılır. Buna uyulmaması, parçalarınızın bir kısmının veya tamamının kaçırılmasına neden olabilir. 

Her parça iki bölümden oluşur: yer paylaşımının uygulanacağı düğümü tanımlayan bir hedef özellik; ve gövdesi hedef düğüme eklenen __overlay__. Yukarıdaki örnek, bu şekilde yazılmış gibi yorumlanabilir: 

/dts-v1/;

/ {
    compatible = "brcm,bcm2708";
};

&i2s {
    status = "okay";
};

Bu bindirmenin, daha sonra yüklenmesi koşuluyla standart bir Ahududu Pi temel Aygıt Ağacı (örneğin, bcm2708-rpi-b-plus.dtb) ile birleştirilmesinin etkisi, durumunu tamamıyla değiştirerek I2S arabirimini etkinleştirmek olacaktır. Ancak, bu bindirmeyi kullanarak derlemeyi denerseniz: 

dtc -I dts -O dtb -o 2nd.dtbo 2nd-overlay.dts

bir hata alırsınız: 

Label or path i2s not found

Derleyicinin i2s etiketini bulmasına izin vermek için base .dtb veya .dts dosyasına referans olmadığından, bu beklenmeyen bir durum olmamalıdır. 

Tekrar deneyin, bu sefer orijinal örneği kullanarak ve çözülmemiş referanslara izin vermek için – @ seçeneğini ekleyin: 

dtc -@ -I dts -O dtb -o 1st.dtbo 1st-overlay.dts

Dtc, üçüncü satırla ilgili bir hata verirse, bindirme çalışması için gerekli uzantılara sahip değildir. Sudo apt-get install device-tree-compiler komutunu çalıştırın ve tekrar deneyin – bu sefer derleme başarıyla tamamlandı. Uygun bir derleyicinin, çekirdek ağacında, dtbs hedefleri kullanıldığında oluşturulan komut dosyaları /dtc/dtc olarak da mevcut olduğunu unutmayın: 

make ARCH=arm dtbs

Derleyicinin ne ürettiğini görmek için DTB dosyasının içeriğini boşaltmak ilginçtir: 

$ fdtdump 1st.dtbo

/dts-v1/;
// magic:           0xd00dfeed
// totalsize:       0x106 (262)
// off_dt_struct:   0x38
// off_dt_strings:  0xe8
// off_mem_rsvmap:  0x28
// version:         17
// last_comp_version:    16
// boot_cpuid_phys: 0x0
// size_dt_strings: 0x1e
// size_dt_struct:  0xb0

/ {
    compatible = "brcm,bcm2708";
    fragment@0 {
        target = <0xdeadbeef>;
        __overlay__ {
            status = "okay";
        };
    };
    __fixups__ {
        i2s = "/fragment@0:target:0";
    };
};

Dosya yapısının ayrıntılı açıklamasından sonra bizim parçamız var. Ama dikkatlice bakın – yazdığımız yerde & i2s şimdi 0xdeadbeef diyor ki, garip bir şey olduğunun bir ipucu. Parçadan sonra yeni bir düğüm var, __fixups__. Bu, çözülmemiş sembollerin adlarını hedef düğümün halkasıyla yaması gereken parçalar içindeki hücrelere giden yol listelerine eşleştiren bir özellik listesi içerir. Bu durumda, yol hedefin 0xdeadbeef değerindedir, ancak parçalar ek düzeltmeler gerektiren çözülmemiş referansları içerebilir. 

Daha karmaşık parçalar yazarsanız, derleyici iki düğüm daha oluşturabilir: __local_fixups__ ve __symbols__. Birincisi, parçalardaki herhangi bir düğümün bir kancasına sahip olması durumunda gereklidir, çünkü birleştirme işlemini gerçekleştiren program, kancalı sayıların sıralı ve benzersiz olmasını sağlamak zorunda kalacaktır. Bununla birlikte, ikincisi, çözülmemiş sembollerin nasıl ele alındığının anahtarıdır. 

Bölüm 1.3’te “orijinal etiketler derlenmiş çıktıda görünmüyor” diyor, ancak – @ anahtarını kullanırken bu doğru değil. Bunun yerine, her etiket __symbols__ düğümündeki bir özellikle sonuçlanır, bir etiketi tam olarak diğer ad düğümü gibi bir yola eşler. Aslında, mekanizma o kadar benzerdir ki, semboller çözülürken, Raspberry Pi yükleyici, “takma ad” düğümünü __symbols__ düğümü yokluğunda arayacaktır. Bu yararlıdır, çünkü yeterli takma adlar sağlayarak, temel DTB dosyalarını oluşturmak için eski bir dtc’nin kullanılmasına izin verebiliriz. 

GÜNCELLEME: Çekirdekteki Dinamik Aygıt Ağacı(Link eklenecek) desteği, kaplamada farklı bir “yerel düzeltme” formatı gerektirir. Eski ve yeni bindirme stilleriyle bir arada yaşama sorunlarından kaçınmak ve diğer bindirme kullanıcıları ile eşleşmek için, eski “name-overlay.dtb” adlandırma planı 4.4’ten itibaren “name.dtbo” ile değiştirildi. Bindirmeler, sadece isimlerle belirtilmelidir ve bunları yükleyen ürün yazılımı veya yardımcı program uygun eki ekleyecektir. Örneğin: 

dtoverlay=awesome-overlay      # This is wrong
dtoverlay=awesome              # This is correct

2.2: Device Tree parameters 

Çok fazla Cihaz Ağacı kaplaması ihtiyacını önlemek ve çevre birimleri kullanıcılarının DTS dosyalarını değiştirme ihtiyacını azaltmak için, Raspberry  Pi yükleyici yeni bir özellik olan Cihaz Ağacı parametrelerini destekler. Bu, çekirdek modüllerinin modprobe ve çekirdek komut satırından parametreleri alma şekline benzer şekilde adlandırılmış parametreler kullanarak DT üzerinde küçük değişikliklere izin verir. Parametreler temel DTB’ler ve HAT kaplamaları dahil kaplamalar tarafından ortaya çıkarılabilir. 

Parametreler DTS’de, köke bir __overrides__ düğümü eklenerek tanımlanır. Adları seçilen parametre adları olan ve değerleri, hedef düğüm için bir kancayı (bir etikete referans) içeren bir dizi olan ve hedef özelliğini gösteren bir dize olan özellikleri içerir; string, integer (cell) ve boolean özellikleri desteklenir. 

2.2.1: String parameters 

Dize parametreleri şöyle bildirilir: 

name = <&label>,"property";

burada etiket ve özellik uygun değerlerle değiştirilir. Dize parametreleri, hedef özelliklerinin büyümesine, daralmasına veya oluşturulmasına neden olabilir 

Durum denilen özelliklerin özel olarak ele alındığını; sıfır / yanlış / evet / açık değerler “tamam” dizgesine dönüştürülürken, sıfır / yanlış / hayır / kapalı “devre dışı” olur. 

2.2.2: Tamsayılı parametreler 

Integer parameters are declared like this: 

name = <&label>,"property.offset"; // 8-bit
name = <&label>,"property;offset"; // 16-bit
name = <&label>,"property:offset"; // 32-bit
name = <&label>,"property#offset"; // 64-bit

etiket, özellik ve ofset uygun değerlerle değiştirilirse; ofset, özelliğin başlangıcına göre (varsayılan olarak ondalık olarak) bayt cinsinden belirtilir ve önceki ayırıcı parametrenin boyutunu belirler. Daha önceki uygulamalardan yapılan bir değişiklikte, tamsayı parametreleri var olmayan özelliklere ya da mevcut bir mülkün sonunun ötesindeki mahsuplara atıfta bulunabilir. 

2.2.3: Boole parametreleri 

Aygıt Ağacı, boole değerlerini sıfır uzunluklu özellikler olarak kodlar; eğer varsa o zaman özellik doğrudur, aksi takdirde yanlış olur. Böyle tanımlanırlar: 

boolean_property; // Set 'boolean_property' to true

Bir özelliğe, tanımlanmayarak yanlış değer atandığını unutmayın. Boole parametreleri şöyle bildirilir: 

name = <&label>,"property?";

burada etiket ve özellik uygun değerlerle değiştirilir. Boolean parametreleri, özelliklerin oluşturulmasına veya silinmesine neden olabilir. 

2.2.4 Yer paylaşımı / parça parametreleri 

Açıklandığı gibi DT parametre mekanizması, bir düğümün adını değiştirememe ve bir parametre kullanıldığında isteğe bağlı özelliklere isteğe bağlı değerler yazma yetersizliği de dahil olmak üzere birçok sınırlamaya sahiptir. Bu sınırlamaların bazılarının üstesinden gelmenin bir yolu şartlı olarak belirli parçaları dahil etmek veya dışlamaktır. 

__Overlay__ düğümünü __dormant__ olarak yeniden adlandırmak suretiyle son birleştirme işleminden (devre dışı bırakılmış) bir fragman çıkarılabilir. Parametre bildirimi sözdizimi, aksi takdirde yasadışı sıfır hedef kanadının aşağıdaki dizenin parça veya kaplama kapsamındaki işlemleri içerdiğini belirtmesine izin verecek şekilde genişletildi. Şimdiye kadar dört operasyon gerçekleştirildi: 

+<n>    // Enable fragment <n>
-<n>    // Disable fragment <n>
=<n>    // Enable fragment <n> if the assigned parameter value is true, otherwise disable it
!<n>    // Enable fragment <n> if the assigned parameter value is false, otherwise disable it

Örnekler 

j

just_one    = <0>,"+1-2"; // Enable 1, disable 2
conditional = <0>,"=3!4"; // Enable 3, disable 4 if value is true,
                          // otherwise disable 3, enable 4.

İ2c-mux yerleşimi bu tekniği kullanır.  

2.2.5 Örnekler 

Aşağıda, değiştirilecek parametrelerle birlikte, farklı özellik türlerinden bazıları verilmiştir: 

/ {
    fragment@0 {
        target-path = "/";
        __overlay__ {

            test: test_node {
                string = "hello";
                status = "disabled";
                bytes = /bits/ 8 <0x67 0x89>;
                u16s = /bits/ 16 <0xabcd 0xef01>;
                u32s = /bits/ 32 <0xfedcba98 0x76543210>;
                u64s = /bits/ 64 < 0xaaaaa5a55a5a5555 0x0000111122223333>;
                bool1; // Defaults to true
                       // bool2 defaults to false
            };
        };
    };

    fragment@1 {
        target-path = "/";
        __overlay__ {
            frag1;
        };
    };

    fragment@2 {
        target-path = "/";
        __dormant__ {
            frag2;
        };
    };

    __overrides__ {
        string =      <&test>,"string";
        enable =      <&test>,"status";
        byte_0 =      <&test>,"bytes.0";
        byte_1 =      <&test>,"bytes.1";
        u16_0 =       <&test>,"u16s;0";
        u16_1 =       <&test>,"u16s;2";
        u32_0 =       <&test>,"u32s:0";
        u32_1 =       <&test>,"u32s:4";
        u64_0 =       <&test>,"u64s#0";
        u64_1 =       <&test>,"u64s#8";
        bool1 =       <&test>,"bool1?";
        bool2 =       <&test>,"bool2?";
        only1 =       <0>,"+1-2";
        only2 =       <0>,"-1+2";
        toggle1 =     <0>,"=1";
        toggle2 =     <0>,"=2";
        not1 =        <0>,"!1";
        not2 =        <0>,"!2";
    };
};

2.2.6: Çok hedefli parametreler 

Aygıt Ağacı içinde birden fazla konumda aynı değeri ayarlamanın uygun olduğu bazı durumlar vardır. Birden fazla parametre oluşturmanın usulsüz yaklaşımı yerine, tek bir parametreye birleştirme yaparak birden çok hedef eklemek mümkündür; 

 __overrides__ {
        gpiopin = <&w1>,"gpios:4",
                  <&w1_pins>,"brcm,pins:0";
        ...
    };

(w1-gpio bindirmesinden alınan örnek) 

Farklı tiplerdeki özellikleri tek bir parametreyle hedeflemenin mümkün olduğunu unutmayın. Bir “enable” parametresini bir durum dizgisine, sıfır veya bir içeren hücrelere ve uygun bir boolean özelliğine makul bir şekilde bağlayabilirsiniz.  

2.2.7: Diğer kaplama örnekleri 

Burada(Link eklenecek) Raspberry Pi / Linux GitHub deposunda barındırılan gittikçe artan sayıda bindirme kaynak dosyası koleksiyonu var. 

Bölüm 3: Raspberry  Pi’de Aygıt Ağaçlarını Kullanma 

3.1: Bindirmeler ve config.txt 

Bir Raspberry Pi’de, bindiricileri uygun bir temel aygıt ağacıyla birleştirmek ve daha sonra tamamen çözülmüş bir Cihaz Ağacı’nı çekirdeğe geçirmek yükleyicinin (başlangıç ​​görüntülerinden biri) görevidir. Temel Aygıt Ağaçları, bcm2708-rpi-b.dtb, bcm2708-rpi-b-plus. -rpi-2-b.dtb. A ve A + modellerinin sırasıyla “b” ve “b-plus” çeşitlerini kullanacağına dikkat edin. Bu seçim otomatiktir ve aynı SD kart görüntüsünün çeşitli cihazlarda kullanılmasına izin verir. 

DT ve ATAG’lerin karşılıklı olarak dışlandığını unutmayın. Sonuç olarak, DT blobunu anlamayan bir çekirdeğe geçirmek, önyükleme hatasına neden olur. Buna karşı koruma sağlamak için yükleyici, mkknlimg yardımcı programı tarafından eklenen bir fragmanla işaretlenmiş DT-uyumluluğunun çekirdek görüntülerini kontrol eder; Bu, yakın zamanda bir çekirdek kaynak ağacının betik dizininde bulunabilir. Römorku olmayan herhangi bir çekirdeğin DT özellikli olmadığı varsayılır. 

Rpi-4.4.y ağacından (ve daha sonra) oluşturulan bir çekirdek DTB’siz çalışmaz, bu nedenle 4.4’ten sonra yayınlandığında, römorksuz bir çekirdeğin DT özellikli olduğu varsayılır. DTOK bayrağı olmayan bir römork ekleyerek veya config.txt içine device_tree = koyarak bunu geçersiz kılabilirsiniz, ancak işe yaramazsa şaşırmayın. N.B. Bunun bir sonucu olarak, eğer çekirdek DT kabiliyetini gösteren bir treyler varsa o zaman device_tree = ihmal edilir. 

Yükleyici şimdi, yukarı akışlı BCM2835 desteğini seçen bcm2835_defconfig kullanılarak yapılanmaları destekler. Bu yapılandırma, bcm2835-rpi-b.dtb ve bcm2835-rpi-b-plus.dtb’nin kurulmasına neden olacaktır. Bu dosyalar çekirdeğe kopyalanırsa ve çekirdek yakın zamanda bir mkknlimg tarafından etiketlenmişse, yükleyici varsayılan olarak bu DTB’lerden birini yüklemeye çalışır. 

Aygıt Ağacı ve yer paylaşımlarını yönetmek için yükleyici birkaç yeni config.txt direktifini destekler: 

dtoverlay=acme-board
dtparam=foo=bar,level=42

Bu, yükleyicinin Raspbian’ın monte ettiği / önyüklendiği bellenim bölümünde bindirmeleri / acme-board.dtbo’yu aramasına neden olacaktır. Daha sonra foo ve level parametrelerini arayacak ve belirtilen değerleri bunlara atayacaktır. 

Yükleyici ayrıca programlanmış bir EEPROM ile ekli bir HAT arayacak ve destek kaplamasını oradan yükleyecektir; bu herhangi bir kullanıcı müdahalesi olmadan gerçekleşir. 

Çekirdeğin Aygıt Ağacı kullandığını söylemenin birkaç yolu vardır: 

• Başlatma sırasındaki “Makine modeli:” çekirdek mesajı, “BCM2709” yerine, “Raspberry Pi 2 Model B” gibi tahtaya özgü bir değere sahip 
• Bir süre sonra, “ATAG yok mu?” Diyen başka bir çekirdek mesajı da olabilir. – bu bekleniyor. 
• / proc / device-tree var ve DT’nin düğümlerini ve özelliklerini tam olarak yansıtan alt dizinler ve dosyalar içeriyor. 

Bir Cihaz Ağacında, çekirdek, belirtilen etkin cihazları destekleyen modülleri otomatik olarak arar ve yükler. Sonuç olarak, bir cihaz için uygun bir DT yerleşimi oluşturarak, cihaz kullanıcılarının / etc / module’leri düzenlemek zorunda kalmamasını; tüm konfigürasyonlar config.txt dosyasına gider ve bir HAT durumunda, bu adım bile gereksizdir. Bununla birlikte, i2c-dev gibi katmanlı modüllerin hala açıkça yüklenmesi gerektiğini unutmayın. 

Bunun asıl amacı, DTB tarafından talep edilmedikçe platform cihazlarının oluşturulmaması nedeniyle, pano destek kodunda tanımlanan platform cihazlarının bir sonucu olarak yüklenen modüllerin kara listeye alınması gerekmemesi. Aslında, mevcut Raspbian görüntüleri kara liste dosyası olmadan gönderiliyor. 

3.2: DT parametreleri 

Yukarıda açıklandığı gibi, DT parametreleri bir cihazın konfigürasyonunda küçük değişiklikler yapmak için uygun bir yoldur. Mevcut temel DTB’ler, özel bindirmeler kullanmadan yerleşik ses, I2C, I2S ve SPI arayüzlerini etkinleştirmek ve kontrol etmek için parametreleri destekler. Kullanımda, parametreler şuna benzer: 

dtparam=audio=on,i2c_arm=on,i2c_arm_baudrate=400000,spi=on

Aynı satıra birden fazla atama yapılabileceğini unutmayın, ancak 80 karakterlik sınırı aşmadığınızdan emin olun. 

İleride ki  varsayılan config.txt şunun gibi bir bölüm içerebilir: 

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

Bazı parametreleri tanımlayan bir kaplamanız varsa, bunlar aşağıdaki satırlarda belirtilebilir: 

dtoverlay=lirc-rpi
dtparam=gpio_out_pin=16
dtparam=gpio_in_pin=17
dtparam=gpio_in_pull=down

veya bindirme satırına şu şekilde eklendi: 

dtoverlay=lirc-rpi:gpio_out_pin=16,gpio_in_pin=17,gpio_in_pull=down

Burada, bindirme adını desteklenen bir sözdizimi değişkeni olan parametrelerinden ayırmak için iki nokta üst üste (:) kullandığınızı unutmayın. 

Kaplama parametreleri sadece bir sonraki kaplama yüklenene kadar kapsamdadır. Aynı isimde, hem kaplama hem de taban tarafından dışa aktarılan bir parametre durumunda, kaplamadaki parametre öncelik kazanır; netlik için, bunu yapmaktan kaçınmanız önerilir. Bunun yerine temel DTB tarafından verilen parametreyi göstermek için, geçerli bindirme kapsamını aşağıdakileri kullanarak sonlandırın: 

dtoverlay=

3.3: Panoya özel etiketler ve parametreler 

Raspberry Pi panoları iki I2C arayüzüne sahiptir. Bunlar nominal olarak bölünmüştür: biri ARM için, diğeri VideoCore için (“GPU”). Neredeyse tüm modellerde i2c1, kamerayı kontrol etmek ve HAT EEPROM’u okumak için kullanılan ARM ve i2c0 – VC’ye aittir. Bununla birlikte, Model B’nin bu rolleri tersine çevrilmiş iki eski düzeltmesi vardır. 

Tüm Pis ile birlikte bir kaplama seti ve parametresi kullanılmasını sağlamak için, ürün yazılımı bazı tahtaya özgü DT parametreleri oluşturur. Bunlar: 

i2c/i2c_arm
i2c_vc
i2c_baudrate/i2c_arm_baudrate
i2c_vc_baudrate

Bunlar i2c0, i2c1, i2c0_baudrate ve i2c1_baudrate takma adlarıdır. Örneğin, gerçekten gerek duyuyorsanız i2c_vc ve i2c_vc_baudrate kullanmanız önerilir – örneğin, bir HAT EEPROM programlıyorsanız. İ2c_vc’ın etkinleştirilmesi Pi Kameranın algılanmasını durdurabilir. 

fragment@0 {
    target = <&i2c_arm>;
    __overlay__ {
        status = "okay";
    };
};

Sayısal değişkenleri kullanan tüm kaplamalar yeni takma adları kullanmak için değiştirilecektir. 

3.4: HAT’lar ve Cihaz Ağacı 

Bir Raspberry Pi HAT, gömülü bir EEPROM’lu “Artı” şeklinde (A +, B + veya Pi 2 B)  Raspberry  Pi için ek bir tahtadır. EEPROM, tahtayı etkinleştirmek için gereken herhangi bir DT kaplamasını içerir ve bu kaplamanın parametreleri de göstermesi mümkündür. 

HAT kaplaması, temel DTB’den sonra bellenim tarafından otomatik olarak yüklenir, bu nedenle parametrelerine, diğer kaplamalar yükleninceye kadar ya da kaplamanın kapsamı dtoverlay = kullanılarak sona erene kadar erişilebilir. Herhangi bir nedenden dolayı HAT bindirmesinin yüklenmesini bastırmak istiyorsanız, dtoverlay = komutunu, diğer dtoverlay veya dtparam yönergelerinin önüne koyun. 

3.5: Dinamik Aygıt Ağacı 

Linux 4.4’ten itibaren, RPi çekirdekleri kaplamaların ve parametrelerin dinamik yüklenmesini destekler. Uyumlu çekirdekler, temel DTB’nin üstüne uygulanan bir yığın bindirmeyi yönetir. Değişiklikler derhal / proc / cihaz ağacına yansır ve modüllerin yüklenmesine ve platform cihazlarının oluşturulup tahrip olmasına neden olabilir. 

Yukarıda “yığın” kelimesinin kullanılması önemlidir – bindirmeler yalnızca yığının üstüne eklenebilir ve çıkarılabilir; istifin aşağısındaki bir şeyi değiştirmek, üstündeki herhangi bir şeyin ilk önce kaldırılmasını gerektirir. 

Kaplamaları yönetmek için bazı yeni komutlar vardır: 

3.5.1 dtoverlay komutu 

dtoverlay, sistem çalışırken bindirmeleri yükleyen ve silen, aynı zamanda mevcut bindirmeleri listeleyen ve yardım bilgilerini görüntüleyen bir komut satırı yardımcı programıdır: 

pi@raspberrypi ~ $ dtoverlay -h
Usage:
  dtoverlay <overlay> [<param>=<val>...]
                           Add an overlay (with parameters)
  dtoverlay -r [<overlay>] Remove an overlay (by name, index or the last)
  dtoverlay -R [<overlay>] Remove from an overlay (by name, index or all)
  dtoverlay -l             List active overlays/params
  dtoverlay -a             List all overlays (marking the active)
  dtoverlay -h             Show this usage message
  dtoverlay -h <overlay>   Display help on an overlay
  dtoverlay -h <overlay> <param>..  Or its parameters
    where <overlay> is the name of an overlay or 'dtparam' for dtparams
Options applicable to most variants:
    -d <dir>    Specify an alternate location for the overlays
                (defaults to /boot/overlays or /flash/overlays)
    -n          Dry run - show what would be executed
    -v          Verbose operation

Config.txt eşdeğerinden farklı olarak, bir bindirmeye ilişkin tüm parametreler aynı komut satırına dahil edilmelidir – dtparam komutu yalnızca temel DTB’nin parametreleri içindir. 

Dikkat edilmesi gereken iki nokta: 

• Çekirdek durumunu değiştiren komut öğeleri (bir şeyler ekleyerek ve çıkartarak) kök ayrıcalığı gerektirir, bu nedenle komutu sudo ile öneklendirmeniz gerekebilir. 
• Yalnızca çalışma zamanında uygulanan kaplamalar ve parametreler boşaltılabilir – üretici yazılımı tarafından uygulanan kaplama veya parametre “fırınlanır”, böylece dtoverlay tarafından listelenmeyecek ve kaldırılamaz. 

 3.5.2 The dtparam command 

dtparam, config.txt dosyasında bir dtparam yönergesi kullanmakla aynı etkiye sahip bir bindirme oluşturur. Kullanımda, bindirmeli – olarak adlandırılan dtoverlay ile büyük ölçüde eşdeğerdir, ancak birkaç küçük fark vardır: 

• dtparam, temel DTB’nin bilinen tüm parametreleri için yardım bilgisini listeler. Dtparam komutuyla ilgili yardım, dtparam -h kullanılarak hala kullanılabilir durumdadır. 
• Kaldırma için bir parametre belirtirken, sadece indeks numaraları kullanılabilir (isimler değil). 

3.5.3 Çalışma zamanı özellikli kaplamalar yazmak için yönergeler 

Bu alan yetersiz belgelenmiştir, ancak işte bazı birikmiş ipuçları: 

• Bir aygıt nesnesinin oluşturulması veya silinmesi, eklenen veya kaldırılan bir düğüm tarafından veya devre dışı bırakılmadan etkin veya tam tersi olarak değişen bir düğümün durumu tarafından tetiklenir. Dikkat – bir “status” özelliğinin olmaması, düğümün etkin olduğu anlamına gelir. 
• Temel DTB’deki mevcut bir düğümün üzerine yazacak bir parça içinde bir düğüm oluşturmayın – çekirdek, benzersiz olması için yeni düğümü yeniden adlandırır. Mevcut bir düğümün özelliklerini değiştirmek istiyorsanız, onu hedefleyen bir parça oluşturun. 
• ALSA, kodeklerinin ve diğer bileşenlerinin kullanımdayken boşaltılmasını engellemez. Bir kaplamayı kaldırmak, hala bir ses kartı tarafından kullanılmakta olan bir codec bileşenini siliyorsa, bir çekirdek istisnasına neden olabilir. Deneyler, aygıtların kaplamadaki parça sırasının tersine silindiğini buldu, bu nedenle bileşenlerin düğümleri sırayla kapanmaya izin verdikten sonra kart için düğümü yerleştirme. 

3.5.4 Uyarılar 

Çalışma zamanında bindirmeleri yükleme, çekirdeğe son eklenen bir işlemdir ve şu ana kadar bunu kullanıcı alanından kabul etmenin bir yolu yoktur. Bu mekanizmanın ayrıntılarını komutların arkasına gizleyerek amaç, farklı bir çekirdek arayüzünün standart hale gelmesi durumunda kullanıcıları değişikliklerden izole etmektir. 

Bazı bindirmeler çalışma zamanında diğerlerinden daha iyi çalışır. Aygıt Ağacının bazı bölümleri yalnızca önyükleme sırasında kullanılır – bir kaplama kullanılarak değiştirilmelerinin bir etkisi olmaz. 

Bazı bindirmeleri uygulamak veya kaldırmak, beklenmeyen davranışlara neden olabilir, bu nedenle dikkatli yapılmalıdır. Bu sudo gerektirmesinin nedenlerinden biri. 

Bir ALSA kartı için kaplamanın boşaltılması, aktif olarak ALSA kullanıyorsa bir şey durdurabilir – LXPanel ses kaydırıcı eklentisi bu etkiyi gösterir. Ses kartlarının yer paylaşımlarının kaldırılmasını sağlamak için, lxpanelctl yardımcı programına iki yeni seçenek verilmiştir – alsastop ve alsastart – ve bunlara sırasıyla bindirmeden veya boşaltılmadan önce ve sonra dtoverlay-öncesi ve dtoverlay-sonrası yardımcı komut dosyalarından çağrılır. 

Bir kaplamayı kaldırmak, yüklü bir modülün boşaltılmasına neden olmaz, ancak bazı modüllerin referans sayısının sıfıra düşmesine neden olabilir. Rmmod -a komutunun iki kez çalıştırılması, kullanılmayan modüllerin boşaltılmasına neden olur. 

Kaplamaların ters sırayla kaldırılması gerekir. Komutlar daha erken olanları kaldırmanıza izin verir, ancak tüm ara olanlar istenmeyen sonuçlara yol açabilecek şekilde kaldırılacak ve yeniden uygulanacaktır. 

Çalışma saatinde / clocks düğümü altına saat eklemek, yeni bir saat sağlayıcısının kaydedilmesine neden olmadığından devm_clk_get, bir bindirmede oluşturulan bir saat için başarısız olur. 

3.6: Desteklenen kaplamalar ve parametreler 

Buradaki tek tek bindirmeleri belgelemek çok zaman alıcı olduğundan, lütfen / boot / bindirmelerdeki bindirme .dtbo dosyalarının yanında bulunan README dosyasına bakın. Eklemeler ve değişikliklerle güncel tutulur. 

Bölüm 4: Sorun giderme ve profesyonel ipuçları 

4.1: Debugging 

Yükleyici eksik bindirmeleri ve hatalı parametreleri atlayacak, ancak eksik veya bozuk temel bir DTB veya başarısız bindirme birleşimi gibi ciddi hatalar varsa, yükleyici DT olmayan bir önyüklemeye geri düşecektir. Bu olursa veya ayarlarınız beklediğiniz gibi davranmazsa, yükleyiciden gelen uyarıları veya hataları kontrol etmeye değer: 

sudo vcdbg log msg

Ekstra hata ayıklama, config.txt dosyasına dtdebug = 1 eklenerek etkinleştirilebilir. 

Çekirdek DT modunda gelmezse, bunun nedeni muhtemelen çekirdeğin geçerli bir fragmanının olmamasıdır. Birini kontrol etmek için knlinfo, birini eklemek için mkknlimg yardımcı programını kullanın. Her iki yardımcı program da mevcut Raspberry Pi çekirdek kaynak ağaçlarının script dizinine dahil edilmiştir. 

DT’nin şu anki durumunun insan tarafından okunabilir bir sunumunu şöyle yapabilirsiniz: 

dtc -I fs /proc/device-tree

Bu, bindirmelerin altta yatan ağaç üzerindeki etkisini görmek için faydalı olabilir. 

Çekirdek modülleri beklendiği gibi yüklenmezse, /etc/modprobe.d/raspi-blacklist.conf; adresinde kara listede olmadıklarını kontrol edin; Cihaz Ağacı kullanılırken kara listeye gerek duyulmamalıdır. Bu, istenmeyen bir şey göstermezse, uyumlu değer için /lib/modules/<version>/modules.alias dosyasını arayarak modülün doğru takma adları dışa aktardığını da kontrol edebilirsiniz. Aksi takdirde, sürücünüz de muhtemelen eksik: 

.of_match_table = xxx_of_match,

Ya da 

MODULE_DEVICE_TABLE(of, xxx_of_match);

Başarısız olursa, depmod başarısız oldu veya güncellenmiş modüller hedef dosya sistemine yüklenmedi. 

4.2: dtmerge ve dtdiff kullanarak bindirmeleri test etme 

Dtoverlay ve dtparam komutlarının yanı sıra bir DTB – dtmerge öğesine bindirme uygulamak için bir yardımcı programdır. Bunu kullanmak için öncelikle iki yoldan biriyle edinilebilecek temel DTB’nizi edinmeniz gerekir: 

1. a) /proc/ device-tree içindeki canlı DT durumundan oluşturun: 

dtc -I fs -O dtb -o base.dtb /proc/device-tree

Bu, bugüne kadar uyguladığınız, config.txt dosyasında veya çalışma zamanında yükleyerek yükleyeceğiniz tüm katmanları ve parametreleri içerecektir; bu, istediğiniz şekilde olabilir veya olmayabilir. Alternatif olarak … 

1. b) kaynakDTB’lerden/ boot içindeki kaynaklardan kopyalayın. Bu, bindirmeleri ve parametreleri içermez, ancak bellenim tarafından yapılan diğer değişiklikleri de içermez. Tüm bindirmelerin test edilmesini sağlamak için dtmerge yardımcı programı, tahtaya özgü bazı takma adları (“i2c_arm”, vb.) Oluşturacaktır, ancak bu, birleştirme sonucunun, orijinal DTB’den beklediğinizden daha fazla farklılık içereceği anlamına gelir. Bunun çözümü kopyayı yapmak için dtmerge kullanmaktır: 

dtmerge /boot/bcm2710-rpi-3-b.dtb base.dtb -

(-, mevcut olmayan bir kaplama adını belirtir). 

Artık bir bindirme veya parametre uygulamayı deneyebilirsiniz: 

dtmerge base.dtb merged.dtb - sd_overclock=62
dtdiff base.dtb merged.dtb

Dönüş 

--- /dev/fd/63  2016-05-16 14:48:26.396024813 +0100
+++ /dev/fd/62  2016-05-16 14:48:26.396024813 +0100
@@ -594,7 +594,7 @@
                };

                sdhost@7e202000 {
-                       brcm,overclock-50 = <0x0>;
+                       brcm,overclock-50 = <0x3e>;
                        brcm,pio-limit = <0x1>;
                        bus-width = <0x4>;
                        clocks = <0x8>;

Farklı kaplamaları veya parametreleri de karşılaştırabilirsiniz. 

dtmerge base.dtb merged1.dtb /boot/overlays/spi1-1cs.dtbo
dtmerge base.dtb merged2.dtb /boot/overlays/spi1-2cs.dtbo
dtdiff merged1.dtb merged2.dtb

Dönüt : 

-- /dev/fd/63  2016-05-16 14:18:56.189634286 +0100
+++ /dev/fd/62  2016-05-16 14:18:56.189634286 +0100
@@ -453,7 +453,7 @@

                        spi1_cs_pins {
                                brcm,function = <0x1>;
-                               brcm,pins = <0x12>;
+                               brcm,pins = <0x12 0x11>;
                                phandle = <0x3e>;
                        };

@@ -725,7 +725,7 @@
                        #size-cells = <0x0>;
                        clocks = <0x13 0x1>;
                        compatible = "brcm,bcm2835-aux-spi";
-                       cs-gpios = <0xc 0x12 0x1>;
+                       cs-gpios = <0xc 0x12 0x1 0xc 0x11 0x1>;
                        interrupts = <0x1 0x1d>;
                        linux,phandle = <0x30>;
                        phandle = <0x30>;
@@ -743,6 +743,16 @@
                                spi-max-frequency = <0x7a120>;
                                status = "okay";
                        };
+
+                       spidev@1 {
+                               #address-cells = <0x1>;
+                               #size-cells = <0x0>;
+                               compatible = "spidev";
+                               phandle = <0x41>;
+                               reg = <0x1>;
+                               spi-max-frequency = <0x7a120>;
+                               status = "okay";
+                       };
                };

                spi@7e2150C0 {

4.3: Belirli bir Cihaz Ağacını Zorlamak 

Varsayılan DTB’ler tarafından desteklenmeyen çok özel gereksinimleriniz varsa (özellikle, ARCH_BCM2835 projesi tarafından kullanılan salt DT yaklaşımını deneyen kişiler) veya yalnızca kendi DT’lerinizi yazmayı denemek istiyorsanız, Bunun gibi alternatif bir DTB dosyası yüklemek için yükleyici: 

device_tree=my-pi.dtb

4.4: Aygıt Ağacı kullanımını devre dışı bırakma 

4.4 çekirdeğe geçiş ve daha fazla akış yukarı sürücü kullanımı nedeniyle Pi çekirdeklerinde Aygıt Ağacı kullanımı gerekir. DT kullanımını devre dışı bırakma yöntemi aşağıdakileri eklemektir: 

device_tree=

config.txt için. Bununla birlikte, eğer çekirdeğin DT yeteneğini belirten bir mkknlimg fragmanı varsa, o zaman bu yönerge dikkate alınmayacaktır. 

4.5: Kısayollar ve sözdizimi çeşitleri 

Yükleyici birkaç kısayoldan anlıyor: 

dtparam=i2c_arm=on
dtparam=i2s=on

kısaltılabilir: 

dtparam=i2c,i2s

(i2c, i2c_arm takma adıdır ve = açık kabul edilir). Ayrıca uzun form versiyonlarını da kabul eder: device_tree_overlay ve device_tree_param. 

Yükleyici, boşluk ve sütunların ayırıcı olarak kullanılmasını kabul etmek için kullanılır, ancak bunlar için destek basitliği durdurulur ve bu nedenle tırnak işaretleri olmadan parametre değerleri içinde kullanılabilir. 

4.6: config.txt dosyasında mevcut olan diğer DT komutları 

device_tree_address Bu, bellenimin aygıt ağacını yüklediği adresi geçersiz kılmak için kullanılır (dt-blob değil). Varsayılan olarak üretici yazılımı uygun bir yer seçecektir. 

device_tree_end Bu, yüklü cihaz ağacına (özel) bir limit belirler. Varsayılan olarak, aygıt ağacı kullanılabilir belleğin sonuna kadar büyüyebilir; bu da neredeyse kesinlikle gerekli olan şeydir. 

dtdebug Sıfır değilse, aygıt yazılımının aygıt ağacı işlemesi için bazı ek günlükleri açın. 

enable_uart Birincil / konsol UART’ı etkinleştirin (Pi3’te ttyS0, aksi takdirde ttyAMA0 – pi3-miniuart-bt gibi bir bindirmeyle değiştirilmediği sürece). Birincil UART ttyAMA0 ise, enable_uart varsayılan olarak 1 (etkin), aksi takdirde varsayılan 0 (devre dışı) olur. Bunun nedeni, çekirdek frekansının, ttyS0’ı kullanılamaz hale getirecek değişimin durdurulması gerekmesidir, bu nedenle enable_uart = 1, core_freq = 250 (force_turbo = 1 olmadığı sürece) anlamına gelir. Bazı durumlarda bu bir performans çarpmasıdır, bu nedenle varsayılan olarak kapalıdır. UART’lar hakkında daha fazla bilgiyi burada bulabilirsiniz. 

overlay_prefix Kaplamaların yükleneceği alt dizini / öneki belirtir – varsayılanları “kaplamalar /” olarak ayarlar. Sonuna “/” dikkat edin. İstenirse, her dosyaya bir önek eklemek için final “/” den sonra bir şeyler ekleyebilirsiniz, ancak bu gerekli olmayabilir.