Linux源碼的arch/powerpc/boot/dts/目錄下存放了很多dts文件，可以作為參考文件。另外dtc編譯器在內核源碼2.6.25版本之後已經被包含進去。在2.6.26版本之後，生成blob的簡單規則已經加入makefile，如下命令：
$ make ARCH=powerpc canyonlands.dtb
也可以根據自己的硬體修改好dts文件後，用下面類似命令生成dtb文件。
$ dtc -f -I dts -O dtb -R 8 -S 0x3000 test.dts > mpc836x_mds.dtb
$ mkimage -A ppc -O Linux -T flat_dt -C none -a 0x300000 -e 0 -d mpc836x_mds.dtb mpc836x_mds.dtu
2. ZYNQ+linux網口調試筆記（3）PL-ETH
在ZYNQ上使用gigE Vision協議的網路介面相機。
第一步：調通PS側網口GEM0（Xilinx BSP默認配好）。
第二步：調通PS側網口GEM1（見前一篇文檔：開發筆記(1)）。
第三步：調通PL側網口（本文闡述）。
第四步：在PL側網口上驗證Jumbo Frame特性，並在應用層適配gigE Vision協議。
根據《xapp1082》可知，PL側的PHY支持1000Base-X和SGMII兩種配置，這兩種配置對應兩種不同的PHY引腳介面（連接到MAC）。而我們的hdf文件使用的是1000Base-X的配置。
關於網口的Linux驅動，我們在官網找到一份資料： Xilinx Wiki - Zynq PL Ethernet 。資料很長，我們只看與我們相關的2.4.1 PL Ethernet BSP installation for 1000Base-X」這一章節就可以了。
首先導入FPGA設計同事提供的hdf文件：
在彈出的圖形界面里，進入Subsystem AUTO Hardware Settings——Ethernet Settings——Primary Ethernet，確認可以看到PL側網路設備axi_ethernet_0，說明hdf文件里已包含了必要的網口硬體信息：
上圖中被選中的網口將成為Linux上的設備eth0。這里我們默認選擇ps7_ethernet_0，即使用GEM0作為首選網口。
啟用Xilinx AXI Ethernet驅動
進入Device Drivers -- Network device support – 選中Xilinx AXI Ethernet（以及Xilinx Ethernet GEM，這是PS側網口的驅動）
進入Networking support – 選中 Random ethaddr if unset
進入Device Drivers -- Network device support -- PHY Device support and infrastructure – 啟用Drivers for xilinx PHYs
進入~~~~Device Drivers -- DMA Engine Support -– 禁用~~~~Xilinx AXI DMAS Engine~~~ （對應的配置項名為 ~~ CONFIG_XILINX_DMA ~~~）
注意： Xilinx Wiki里對設備樹節點的引用有誤（&axi_ethernet），導致編譯報錯，應改為&axi_ethernet_0。
註：PL-ETH驅動所在路徑：<project>/build/tmp/work-shared/plnx_arm/kernel-source/drivers/net/ethernet/xilinx/xilinx_axienet_main.c和xilinx_axienet_mdio.c。對應的內核配置項為CONFIG_NET_VENDOR_XILINX和CONFIG_XILINX_AXI_EMAC。
啟用ethtool和tcpmp（調試用，非必須）：
然後將生成的BOOT.BIN和image.ub拷貝到SD卡根目錄下，將SD卡插入板子上，上電運行。
上電後，使用ifconfig eth1查看網口信息，觀察MAC地址與設置的一致，且ifconfig eth1 192.168.1.11 up沒有報錯。
測試網路通路：ping PC是通的。說明網口工作正常。
Linux下eth1（即PL-ETH）的MAC地址有誤
問題描述：
開機列印：
注意：
MAC地址是錯的，驅動里解析出的是GEM0的MAC地址。
試驗發現，即使在system-user.dtsi里不寫local-mac-address，也照樣解析出的是GEM0的MAC。
而將system-user.dtsi里的local-mac-address改名為pl-mac-address，並將驅動里解析的字元串也對應更改為pl-mac-address，則可以正確解析出來：
Passing MAC address to kernel via Device Tree Blob and U-Boot：
http://zedboard.org/content/passing-mac-address-kernel-device-tree-blob
通過更改u-boot環境變數和設備樹，為每個板子設置一個獨特的MAC地址：
https://www.xilinx.com/support/answers/53476.html
U-Boot里的環境變數ethaddr會覆蓋掉設備樹里pl-eth的local-mac-addr欄位，從而影響Linux啟動後的網卡MAC地址；
但U-Boot里的環境變數ipaddr不會對Linux啟動後的配置產生任何影響。因為設備樹里根本就沒有關於IP地址的配置。
phy-mode怎麼會是sgmii？查了下官方的提供的BSP里，也是「sgmii」。說明這個沒問題。具體原因不清楚。
@TODO: 設備樹里的中斷號的順序如何影響功能？
為何讀出來的IRQ號不對呢？這是因為這里讀到的不是硬體的中斷號，而是經過系統映射之後的軟體IRQ number。兩者不具有線性關系。
關於中斷號的疑問：
Linux上的網口eth0、eth1的順序，似乎是按照phy地址從小到大來排布的。
Xilinx xapp1082-zynq-eth.pdf (v5.0) July 16, 2018
https://www.xilinx.com/support/documentation/application_notes/xapp1082-zynq-eth.pdf
Xilinx Wiki - Zynq PL Ethernet:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841633/Zynq+PL+Ethernet
Xilinx Wiki - Linux Drivers:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841873/Linux+Drivers
Xilinx Wiki - Linux Drivers - Macb Driver:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841740/Macb+Driver
Xilinx Wiki - Zynq Ethernet Performance:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841743/Zynq+Ethernet+Performance
查到關於Jumbo frame MTU的定義，當前值為9000，可否改大一些？
驅動源碼里關於jumbo frame的說明：
設置MTU為9000，發現ping包最大長度只能設為ping 192.168.1.10 -s 1472
https://lore.kernel.org/patchwork/patch/939535/
【完】
3. Linux如何及時響應外部中斷
FPGA每隔100us給運行linux的ARM一個中斷，要求在20us內響應中斷，並讀走2000*16bit的數據。
目前主要的問題是，當系統同時發生多個中斷時，會嚴重影響linux對FPGA中斷的響應時間。如何解決？
1、首先想到了ARM的FIQ，它可以打斷IRQ中斷服務程序，保證對外部FIQ的及時響應。但是發現linux只實現了IRQ，沒有顯示FIQ。
linux是從devicetree讀取中斷號，加入中斷向量表的。
interrupts = <0x0 0x32 0x0>;中的第一個欄位0表示非共享中斷，非零表示共享中斷，SDK產生的dts統一為0，此時第二欄位的值比XPS中的小32；如果第一欄位非零，則第二欄位比XPS小16.
最後欄位表示中斷的觸發方式。
IRQ_TYPE_EDGE_RISING =0x00000001,
IRQ_TYPE_EDGE_FALLING =0x00000002,
IRQ_TYPE_LEVEL_HIGH =0x00000004,
IRQ_TYPE_LEVEL_LOW =0x00000008,
很明顯，devicetree根本沒有提供通知linux有FIQ的渠道。
2、再來看linux的IRQ
linux的中斷分為上半部和下半部，上半部運行在IRQ模式，會屏蔽所有中斷，下半部運行在SVC模式，會重新打開中斷。
也就是說，當一個中斷的上半部正在運行時（不能再次響應中斷），FPGA的中斷是不能被linux響應的；
反過來，當FPGA中斷的上半部正在運行時（不能再次響應中斷），其他的中斷也不能被linux響應；
unsigned long flags;
...
local_irq_save(flags);
....
local_irq_restore(flags);
3.
ARM有七種模式，我們這里只討論SVC、IRQ和FIQ模式。
我們可以假設ARM核心有兩根中斷引腳（實際上是看不見的），一根叫 irq pin, 一根叫fiq pin.
在ARM的cpsr中，有一個I位和一個F位，分別用來禁止IRQ和FIQ的。
先不說中斷控制器，只說ARM核心。正常情況下，ARM核都只是機械地隨著pc的指示去做事情，當CPSR中的I和F位為1的時候，IRQ和FIQ全部處於禁止狀態。無論你在irq
pin和fiq pin上面發什麼樣的中斷信號，ARM是不會理你的，你根本不能打斷他，因為他耳聾了，眼也瞎了。
在I位和F位為0的時候，當irq
pin上有中斷信號過來的時候，就會打斷arm的當前工作，並且切換到IRQ模式下，並且跳到相應的異常向量表（vector)位置去執行代碼。這個過程是自動的，但是返回到被中斷打斷的地方就得您親自動手了。當你跳到異常向量表，處於IRQ的模式的時候，這個時候如果irq
pin上面又來中斷信號了，這個時候ARM不會理你的，irq
pin就跟秘書一樣，ARM核心就像老闆，老闆本來在做事，結果來了一個客戶，秘書打斷它，讓客戶進去了。而這個時候再來一個客戶，要麼秘書不斷去敲門問，要麼客戶走人。老闆第一個客戶沒有會見完，是不會理你的。
但是有一種情況例外，當ARM處在IRQ模式，這個時候fiq pin來了一個中斷信號，fiq
pin是什麼？是快速中斷呀，比如是公安局的來查刑事案件，那才不管你老闆是不是在會見客戶，直接打斷，進入到fiq模式下，並且跳到相應的fiq的異常向量表處去執行代碼。那如果當ARM處理FIQ模式，fiq
pin又來中斷信號，又就是又一批公安來了，那沒戲，都是執法人員，你打不斷我。那如果這個時候irq
pin來了呢？來了也不理呀，正在辦案，還敢來妨礙公務。
所以得出一個結論： IRQ模式只能被FIQ模式打斷，FIQ模式下誰也打不斷。
在打不斷的情況下，irq pin 或 fiq pin隨便你怎麼發中斷信號，都是白發。
所以除了fiq能打斷irq以外，根本沒有所謂中斷嵌套的情況。
Linux不用FIQ,只用到了IRQ。但是我們有時候一個中斷需要處理很長時間，那我們就需要佔用IRQ模式那麼長的時間嗎？沒有，linux在IRQ模式下只是簡單的記錄是什麼中斷，馬上就切換回了SVC模式，換句話說，Linux的中斷處理都是在SVC模式下處理的。
只不過SVC模式下的ISR上半部關閉了當前中斷線，下半部才重新打開
4. Linux內核中斷之獲取中斷號
Linux內核中可使用 platform_get_irq() 函數獲取 dts 文件中設置的中斷號。
函數原型： int platform_get_irq(struct platform_device *dev, unsigned int num)
定義文件： driversaseplatform.c
中斷號獲取函數 platform_get_irq() 調用流程如下：
rk3399 使用的是 GICv3 ，對應 irq_domain->name 。
文件： drivers/irqchip/irq-gic-v3.c 。
translate() 函數實現如下：
以 RockPI 4A 單板 Debian 系統Linux 4.4內核中的獲取 HDMI 中斷號為例。
1、查找中斷號
從手冊「Rockchip RK3399 TRM V1.3 Part1.pdf」中，可以查到 HDMI_IRQ 中斷號，即55。
2、 dts 配置
文件： arch/arm64/boot/dts/rockchip/rk3399.dtsi
hdmi 使用的是 GIC_SPI 中斷，按照 gic_irq_domain_translate() 函數中處理，需要將中斷號55減去32，得到 dts 中的中斷號23。
註： interrupts = <中斷類型 中斷號 中斷觸發類型 中斷分區(對應哪個CPU cluster，PPI類型中斷特有)>
3、驅動函數
文件： driversgpudrm ockchipdw_hdmi-rockchip.c
此時， irq 返回值為55。
後續會介紹 GIC 和中斷注冊等實現函數。
5. Linux內核dvfs之cpufreq配置
本文基於 RockPi 4A 單板 Linux4.4 內核介紹 OPP Table 。
內核中將頻咐游率、電壓的相關配置放在 DTSI 文件中，這些配置信息組成的節點被稱為物簡遲 OPP Table（Operating Performance Points） 。
定義文件： arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi ,內容如下：
上面節點中的相關屬性含義如下：
1、 opp-shared ：表示 opp-table1 是小核的各 CPU 共用。
2、 rockchip,temp-hysteresis ：遲滯參數，防止頻繁進入高溫或低溫，單位：毫攝氏度。
3、 rockchip,low-temp ：低溫閾值。小於該值時，進入低溫，大於『該值+遲滯參數』時，恢復常溫。
4、 rockchip,low-temp-min-volt ：低溫下最低電壓，單位：微伏。
5、 nvmem-cells ：從 eFUSE 中讀取相關信息值（小核漏電流）。
6、 rockchip,pvtm-voltage-sel ：min-pvtm（單位KHz）、max-pvtm（單位KHz）和 voltage-selector (用於匹配 opp 節點中 opp-microvolt-L* 屬性的序列號)。例：pvtm值為：0 ~ 143500 使用 opp-microvolt-L0 ，143501 ~ 148500使用 opp-microvolt-L1
7、 rockchip,pvtm-freq ：時鍾頻率（KHz），在獲取 pvtm 的頻率前，先設置 CPU 頻率。
8、 rockchip,pvtm-volt ：電壓（微伏），在獲取 pvtm 的頻率前，先設置 CPU 電壓。
9、 rockchip,pvtm-ch ： PVTM 通道，格式<通道號 sel的序號>
10、 rockchip,pvtm-sample-time ： PVTM 采樣時間，單位：毫秒。
11、 rockchip,pvtm-number ： PVTM 采樣個數。
12、 rockchip,pvtm-error ：允許采樣數據之間的誤差。
13、 rockchip,pvtm-ref-temp ：參考溫度。
14、 rockchip,pvtm-temp-prop ： PVTM 隨溫度變化的比例系數，格式<小於參考溫度的比例系數 大於參考溫度的比例系數>。
15、 rockchip,thermal-zone ：獲取溫度的 thermal-zone 。
16、 opp-microvolt-L* ：電壓(微伏)，格式<target min max>
17、 clock-latency-ns ：完成變頻需要的時間，單位：納秒。
在 RK3399 中，除了配置上述小核的 opp table 外，還設置了大核（ cluster1_opp ）、 gpu(gpu_opp_table) 等的相關值。查看命令如下：
註：
CPU PVTM(Process Voltage Temperature Monitor) 是一個位於 CPU 附近，能罩李反應出不同晶元之間性能差異的模塊，受工藝，電壓和溫度 的影響。
參考：
Documentation/devicetree/bindings/cpufreq/cpufreq-rockchip.txt
Documentation/devicetree/bindings/cpufreq/cpufreq-rockchip.txt