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