我在设备树上遇到了一些奇怪的问题。我发现改变.dtbo文件的名称会改变内核的行为!
我修改了/lib/firmware中的BB-SPIDEV1-00A0.dts,使用Angstrom系统:
/*
* Copyright (C) 2013 CircuitCo
*
* Virtual cape for SPI1 on connector pins P9.29 P9.31 P9.30 P9.28
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
/dts-v1/;
/plugin/;
/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";
/* identification */
part-number = "BB-SPI1-01";
version = "00A0";
/* state the resources this cape uses */
exclusive-use =
/* the pin header uses */
"P9.31", /* spi1_sclk */
"P9.29", /* spi1_d0 */
"P9.30", /* spi1_d1 */
"P9.28", /* spi1_cs0 */
"P9.42", /* spi1_cs1 */
/* the hardware ip uses */
"spi1";
fragment@0 {
target = <&am33xx_pinmux>;
__overlay__ {
/* default state has all gpios released and mode set to uart1 */
bb_spi1_pins: pinmux_bb_spi1_pins {
pinctrl-single,pins = <
0x190 0x13 /* mcasp0_aclkx.spi1_sclk, OUTPUT_PULLUP | MODE3 */
0x194 0x33 /* mcasp0_fsx.spi1_d0, INPUT_PULLUP | MODE3 */
0x198 0x13 /* mcasp0_axr0.spi1_d1, OUTPUT_PULLUP | MODE3 */
0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */
0x164 0x12 /* eCAP0_in_PWM0_out.spi1_cs1 OUTPUT_PULLUP | MODE2 */
0x1A0 0x32 /* Other P42 pin, INPUT_PULLUP */
>;
};
};
};
fragment@1 {
target = <&spi1>; /* spi1 is numbered correctly */
__overlay__ {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&bb_spi1_pins>;
#address-cells = <1>;
#size-cells = <0>;
spi1_0{
#address-cells = <1>;
#size-cells = <0>;
compatible = "spidev";
reg = <0>;
spi-max-frequency = <16000000>;
};
spi1_1{
#address-cells = <1>;
#size-cells = <0>;
compatible = "spidev";
reg = <1>;
spi-max-frequency = <16000000>;
};
};
};
};
我把它编译成了两个名称:BB-SPIDEV1-00A0.dtbo和BB-SPI1-01-00A0.dtbo。
当我在/sys/devices/bone_capemgr.9/slots中加载其中一个时,spidev的行为会有所不同!
使用BB-SPIDEV1时,spidev1.0正常工作,没有任何问题。但是spidev1.1的片选不起作用!引脚42处于错误的模式,并且该引脚没有与spi1分配。
另一方面,使用BB-SPI1-01(此名称并不重要,给出另一个名称也一样,只要与BB-SPIDEV1不同即可),引脚42被正确分配:
root@beaglebone:/sys/kernel/debug/pinctrl/44e10800.pinmux# cat pinmux-pins | grep spi
pin 89 (44e10964): 481a0000.spi (GPIO UNCLAIMED) function pinctrl_spi1_pins group pinctrl_spi1_pins
pin 100 (44e10990): 481a0000.spi (GPIO UNCLAIMED) function pinctrl_spi1_pins group pinctrl_spi1_pins
pin 101 (44e10994): 481a0000.spi (GPIO UNCLAIMED) function pinctrl_spi1_pins group pinctrl_spi1_pins
pin 102 (44e10998): 481a0000.spi (GPIO UNCLAIMED) function pinctrl_spi1_pins group pinctrl_spi1_pins
pin 103 (44e1099c): 481a0000.spi (GPIO UNCLAIMED) function pinctrl_spi1_pins group pinctrl_spi1_pins
pin 104 (44e109a0): 481a0000.spi (GPIO UNCLAIMED) function pinctrl_spi1_pins group pinctrl_spi1_pins
在良好模式下:
root@beaglebone:/sys/kernel/debug/pinctrl/44e10800.pinmux# cat pins | grep 964
pin 89 (44e10964) 00000012 pinctrl-single
但是这一次,spidev1.0工作不正常。MISO线路(BBB的输入)只能看到0,即使它是错误的(我用示波器检查过)。那么问题可能是什么呢?提前感谢。
spi-cpha;
,它位于片段1、通道0下的spi-max-frequency
之下,并且您的引脚复用存在几个差异:SPI1_SCLK可能是INPUT_PULLUP,此外我没有看到P9_42B(0x1A0)与SPI子系统之间的任何关系 - 您可能将其与具有SPI1_SCLK(模式4)和SPI1_CS1(模式2)的P9_42A(0x164)混淆了。 P9_42B的模式2是'MCASPO_AXR2'。 - TekuConcept多通道音频串行端口子系统0
[mcasp0]中,作为BB-BONELT-HDMIN叠加层的一部分。要删除HDMI叠加层,请按照此页面底部的说明进行操作:http://tekuconcept.blogspot.com/2014/02/gpio-beaglebone-and-bash.html,然后查看发生了什么。 - TekuConceptcapemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
并且它们已经被卸载了(我可以通过cat $SLOTS
看到)。 - user3714405