Enable Device Tree Overlay for Beaglebone Black linux 4.14-ti - linux

I have a problem with Devicetree overlay.
My overlay file is here;
/{
compatible = "ti,beaglebone", "ti,beaglebone-black";
/* Identification */
part_number = "GPIO_Overlays";
/* Version */
version = "00A0";
exclusive-use =
"P9.31",
"P9.17",
"P9.29",
"P9.18",
"P9.28",
"P9.27",
"P9.30",
"P9.24",
"P9.26",
"P9.20";
/* To be Continue */
/*
* Free up the pins used by the cape from the pinmux helpers.
*/
fragment#0{
target = <&ocp>;
__overlay__{
P9_31_pinmux { status = "disabled"; };
P9_17_pinmux { status = "disabled"; };
P9_29_pinmux { status = "disabled"; };
P9_18_pinmux { status = "disabled"; };
P9_28_pinmux { status = "disabled"; };
P9_27_pinmux { status = "disabled"; };
P9_30_pinmux { status = "disabled"; };
P9_24_pinmux { status = "disabled"; };
P9_26_pinmux { status = "disabled"; };
P9_20_pinmux { status = "disabled"; };
};
};
/*
* Free up the gpios used by the cape-universal gpio helpers.
*/
fragment#1 {
target = <&ocp>;
__overlay__{
cape-universal { status = "disabled"; };
};
};
/*
* Setting up to gpio pins.
*/
fragment#2{
target = <&am33xx_pinmux>;
__overlay__{
GPIO_Overlays: GPIO_Overlays{
pinctrl-single,pins = <
0x190 0x37 /* Input_PullUp | Mode 7 */
0x15C 0x37 /* Input_PullUp | Mode 7 */
0x194 0x37 /* Input_PullUp | Mode 7 */
0x158 0x17 /* Output_PullUp | Mode 7 */
0x19C 0x37 /* Input_PullUp | Mode 7 */
0x1a4 0x37 /* Input_PullUp | Mode 7 */
0x198 0x17 /* Output_PullUp | Mode 7 */
0x184 0x17 /* Output_PullUp | Mode 7 */
0x180 0x17 /* Output_PullUp | Mode 7 */
0x178 0x17 /* Output_PullUp | Mode 7 */
/* BONE_P9_20 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) */
>;
};
};
};
fragment#3{
target = <&ocp>;
__overlay__{
GPIO{
compatible = "gpio-keys";
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&GPIO_Overlays>;
};
};
};};
Then I add this .dts file to lib/firmware.
I have compiled this .dts file. The output is .dtbo file.
My compile method is here;
dtc -O dtb -o /lib/firmware/GPIO_Overlays-00A0.dtbo -b 0 -# /lib/firmware/GPIO_Overlays-00A0.dts
When I reboot the BBB, These pins are reverting to their old state.
What is the worng? I couldn't solve this problem.
Can anyone help me?
Note: I use the linux-4.14-rt and debian 9.5.
EDIT: When I reboot the BBB, I get this error.
[ 0.717426] pinctrl-single 44e10800.pinmux: pin PIN13 already requested by ocp:helper; cannot claim for ocp:P8_11_pinmux
[ 0.728435] pinctrl-single 44e10800.pinmux: pin-13 (ocp:P8_11_pinmux) status -22
[ 0.736399] pinctrl-single 44e10800.pinmux: could not request pin 13 (PIN13) from group pinmux_P8_11_default_pin on device pinctrl-single
[ 0.750487] bone-pinmux-helper ocp:P8_11_pinmux: Error applying setting, reverse things back

See here: https://github.com/beagleboard/BeagleBoard-DeviceTrees
There you can see how they produce specific .dts files and then you can rebuild their entire .dts file archive into a few of your changed favorites.
Also, I think to build after cloning, one would just type make in the dir.
So:
git clone https://github.com/beagleboard/BeagleBoard-DeviceTrees
cd BeagleBoard-DeviceTrees
look around in src/arm and src/arm/overlays
change up what you think may need changing and then...
make
That may be a cure to you worries.

Related

Device Tree Configuration for PTN5110 with an iMX6UL and Kernel 5.15

Same Hardware, new Kernel
We are trying to update to the new Kernel 5.15.32 (old Kernel 4.19.72) but the USB-PD Chip (PTN5110) just does not work:
When we start the module tcpci with our Device Tree (see below) we get the following messages:
devel#europa:/usr/lib/modules/5.15.32+g4122737b2fca$ sudo modprobe tcpci
[ 139.282440] OF: graph: no port node found in /soc/bus#2100000/i2c#21f8000/ptn5110#50
[ 139.332044] OF: graph: no port node found in /soc/bus#2100000/i2c#21f8000/ptn5110#50/connector
[ 139.341524] OF: graph: no port node found in /soc/bus#2100000/i2c#21f8000/ptn5110#50/connector
We did try to specify the port but were unlucky so far (nothing seams to work and we are trying for a few weeks now). The DT below worked wonderful in the old kernel but not the new one.
After loading the module we see some communication over the I2C port and everything seams to work fine. As soon as we plug in a USB connection the Kernel gets flooded with IRQ requests (or so it seams). The I2C bus is filled with data exchange and none of the consoles are reacting to any keystroke. After unplugging the USB connection the system reacts normal again. (the system seams to be blocked completely)
Our device tree:
/ {
regulators {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <0>;
reg_usb_otg1_vbus: regulator#2 {
compatible = "regulator-fixed";
reg = <2>;
regulator-name = "usb_otg1_vbus";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usb_otg1_vbus>;
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
gpio = <&gpio2 8 GPIO_ACTIVE_HIGH>;
enable-active-high;
status = "okay";
};
};
};
&usbotg1 {
/*pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usbotg1>;*/
dr_mode = "otg";
status = "okay";
disable-over-current;
vbus-supply = <&reg_usb_otg1_vbus>;
};
&i2c4 {
clock-frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c4>;
status = "okay";
usb_pd: ptn5110#50 {
compatible = "nxp,ptn5110";
reg = <0x50>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usb_pd>;
interrupt-parent = <&gpio2>;
interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
wakeup-source;
usb_con: connector {
compatible = "usb-c-connector";
label = "USB-C";
data-role = "dual";
power-role = "dual";
try-power-role = "sink";
source-pdos = <PDO_FIXED(VSAFE5V, 2000, PDO_FIXED_USB_COMM | PDO_FIXED_DUAL_ROLE)>;
sink-pdos = <PDO_FIXED(VSAFE5V, 2000, PDO_FIXED_USB_COMM | PDO_FIXED_DUAL_ROLE)
//PDO_FIXED(VSAFE5V, 3000, 0)
//PDO_FIXED(9000, 3000, 0)
PDO_FIXED(12000, 3000, 0)
PDO_FIXED(20000, 3000, 0)>;
//PDO_FIXED(20000, 5000, 0)>;
op-sink-microwatt = <10000000>;
};
};
};
&iomuxc {
pinctrl_i2c4: i2c4grp {
fsl,pins = <
MX6UL_PAD_UART2_TX_DATA__I2C4_SCL 0x4001b8b0
MX6UL_PAD_UART2_RX_DATA__I2C4_SDA 0x4001b8b0
>;
};
pinctrl_usb_pd: usbpdgrp {
fsl,pins = <
MX6UL_PAD_ENET2_TX_DATA0__GPIO2_IO11 0x0001b020 /* Alert Interrupt */
MX6UL_PAD_ENET2_TX_CLK__GPIO2_IO14 0x0001b020 /* Fault Interrupt */
>;
};
pinctrl_usb_otg1_vbus: usbotg1 {
fsl,pins = <
MX6UL_PAD_ENET2_RX_DATA0__GPIO2_IO08 0x000000b9
MX6UL_PAD_ENET2_RX_DATA1__USB_OTG1_OC 0x000010b0
>;
};
};
So I did find out that the Chip goes into Fault every time I plug in a USB Connection. (It comes out of the Fault as soon as I unplug the USB)
On the I2C Bus I see that the Kernel Module keeps trying to reset the Fault flag without success.
I see a repeating pattern of:
0x50 Write 0x10
0x50 Read 0x00 0x02
0x50 Write 0x10 0x00 0x02
As I wrote, the chip was working fine with the old Kernel 4.19.72 but not with the new Kernel 5.15.68.
If someone could tell me what is going wrong I would be very thankful.
As it turned out there is a bug in the Kernel Module tcpci that has this effect on the PTN5110 Chip. NXP already has a patch for their Kernel but it was not ported to the Mainline Kernel. I implemented the same patch for the Kernel 5.15.91 and the chip is working flawlessly now. For anyone with the same problem, here my patch:
diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
index 5340a3a3a81b..0d715e091b78 100644
--- a/drivers/usb/typec/tcpm/tcpci.c
+++ b/drivers/usb/typec/tcpm/tcpci.c
## -628,6 +628,9 ## static int tcpci_init(struct tcpc_dev *tcpc)
if (ret < 0)
return ret;
+ /* Clear fault condition */
+ regmap_write(tcpci->regmap, TCPC_FAULT_STATUS, 0x80);
+
if (tcpci->controls_vbus)
reg = TCPC_POWER_STATUS_VBUS_PRES;
else
## -644,7 +647,8 ## static int tcpci_init(struct tcpc_dev *tcpc)
reg = TCPC_ALERT_TX_SUCCESS | TCPC_ALERT_TX_FAILED |
TCPC_ALERT_TX_DISCARDED | TCPC_ALERT_RX_STATUS |
- TCPC_ALERT_RX_HARD_RST | TCPC_ALERT_CC_STATUS;
+ TCPC_ALERT_RX_HARD_RST | TCPC_ALERT_CC_STATUS |
+ TCPC_ALERT_V_ALARM_LO | TCPC_ALERT_FAULT;
if (tcpci->controls_vbus)
reg |= TCPC_ALERT_POWER_STATUS;
/* Enable VSAFE0V status interrupt when detecting VSAFE0V is supported */
## -728,6 +732,13 ## irqreturn_t tcpci_irq(struct tcpci *tcpci)
tcpm_vbus_change(tcpci->port);
}
+ /* Clear the fault status anyway */
+ if (status & TCPC_ALERT_FAULT) {
+ regmap_read(tcpci->regmap, TCPC_FAULT_STATUS, &raw);
+ regmap_write(tcpci->regmap, TCPC_FAULT_STATUS,
+ raw | TCPC_FAULT_STATUS_MASK);
+ }
+
if (status & TCPC_ALERT_RX_HARD_RST)
tcpm_pd_hard_reset(tcpci->port);
I found this solution here: https://source.codeaurora.org/external/imx/linux-imx/commit/drivers/usb/typec/tcpm/tcpci.c?h=lf-5.15.y&id=2a263f918b25725e0434afa9ff3b83b1bc18ef74

Gumstix device tree and SPI

I am attempting to upgrade to a more recent kernel, so I've grabbed the yocto build from https://github.com/gumstix/yocto-manifest and built that. That image successfully boots my unit, so that is a good first step. I had to enable the SPIDEV driver in the kernel, and that part worked.
My board is based on a gumstix Tobi board, and that's what device tree my u-boot loads at boot time. However, I cannot seem to get SPI to work. I have added the following to the file omap3-overo-storm-tobi.dts file:
&omap3_pmx_core {
mcspi1_pins: pinmux_mcspi1_pins {
pinctrl-single,pins = <
OMAP3_CORE1_IOPAD(0x21c8, PIN_INPUT | MUX_MODE0) /* mcspi1_clk.mcspi1_clk */
OMAP3_CORE1_IOPAD(0x21ca, PIN_INPUT | MUX_MODE0) /* mcspi1_simo.mcspi1_simo */
OMAP3_CORE1_IOPAD(0x21cc, PIN_INPUT | MUX_MODE0) /* mcspi1_somi.mcspi1_somi */
OMAP3_CORE1_IOPAD(0x21ce, PIN_INPUT | MUX_MODE0) /* mcspi1_cs0.mcspi1_cs0 */
OMAP3_CORE1_IOPAD(0x21d0, PIN_INPUT | MUX_MODE0) /* mcspi1_cs1.mcspi1_cs1 */
>;
};
};
&mcspi1 {
pinctrl-names = "default";
pinctrl-0 = <&mcspi1_pins>;
spidev#0 {
compatible = "spidev";
spi-max-frequency = <48000000>;
reg = <1>;
spi-cpha;
};
};
Upon a reboot this has successfully created a /dev/spidev1.1 device, but if I attempt to send anything to it I do not see the clock lines or the CS1 line go active. I feel like I'm missing a piece here, but I'm unsure where to go. Any suggestions would be very much appreciated.

gpio-keys not working in combination with I/O expander driver gpio-pca953x (TCA6416A)

I want to integrate/load the gpio-pca953x driver in my Raspberry Pi3 B+ Linux with the help of an DT overlay. This driver is a general I²C controlled I/O expander gpio driver for various chips i.e. TCA6416. I managed to create an dts overlay which enables the driver.
/dts-v1/;
/plugin/;
/ {
compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
fragment#0 {
target = <&i2c1>;
__overlay__ {
status = "okay";
};
};
fragment#1 {
target = <&i2c1>;
__overlay__ {
#address-cells = <1>;
#size-cells = <0>;
tca6416: tca6416#20 {
compatible = "ti,tca6416";
reg = <0x20>;
gpio-controller;
#gpio-cells = <2>;
interrupt-parent = <&gpio>;
interrupts = <18 0x02>; //IRQ_TYPE_EDGE_FALLING
};
};
};
};
There is a new gpiochip /sys/class/gpio/gpiochip488 and also interrupts seems to work.
I thought the next easy step would be to create a virtual input device with the help of the gpio-keys module. But it seems I was wrong.
I created another DT overlay like this:
fragment#1 {
target-path = "/soc";
__overlay__ {
gpio: gpio-button {
compatible = "gpio-keys";
autorepeat;
button#14 {
label = "TestKey";
linux,code = <14>;
gpios = <&tca6416 0 1>;
};
};
};
};
But this time this overlay can never be loaded. The error I got is always that symbol tca6416 can not be found in live device tree symbol table. What am I doing wrong here? Are there any working examples? I also tried to replace tca6416 in gpios above with gpio488 or any other possible name. Neither works.
It seems that the problem is the DTS overlay mechanism it self in some way. tca6416 gets never export as symbol in live tree. My solution is not using the overlay but including an DTS file in one of the main DTS files like bcm2710-rpi-3-b-plus.dts instead.
This include file contains:
&i2c1 {
tca6416_20: tca6416#20 {
compatible = "ti,tca6416";
#gpio-cells = <2>;
reg = <0x20>;
gpio-controller;
interrupt-parent = <&gpio>;
interrupts = <18 IRQ_TYPE_EDGE_FALLING>;
reset-gpios = <&gpio 23 GPIO_ACTIVE_LOW>;
};
};
This works as intended so does gpio-keys.

Enable RS485 mode for max310x SPI-UART converter

In my application I need RS485 interfaces. I am using some UARTs from am3352 but I need few more, so I'm trying to expand using SPI and max3109 chip.
I have successfully added max3109 to my device tree using module max310x - it shows two devices: /dev/ttyMAX0 and /dev/ttyMAX1. Here is the device tree fragment:
&spi1 {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&spi1_pins>;
num_cs = <1>;
cs-gpios = <&gpio2 17 0>;
ti,pindir-d0-out-d1-in;
max310x_0: max0#0 {
compatible = "maxim,max3109";
reg = <0>;
spi-max-frequency = <24000000>;
clocks = <&clk1m8>;
clock-names = "xtal";
interrupt-parent = <&gpio2>;
interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
gpio-controller;
#gpio-cells = <2>;
clk1m8: clk1m8 {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <1843200>;
};
};
};
and the pins:
spi1_pins: pinmux_spi1_pins {
pinctrl-single,pins = <
0x108 (PIN_INPUT_PULLUP | MUX_MODE2) /* (H16) gmii1_col.spi1_sclk */
0x10c (PIN_INPUT_PULLUP | MUX_MODE2) /* (H17) gmii1_crs.spi1_d0 */
0x110 (PIN_INPUT_PULLUP | MUX_MODE2) /* (J15) gmii1_rxer.spi1_d1 */
>;
};
UARTs from max3109 are connected to rs232/rs485 converter with max3109's RTSn pins conected to both DE and RE pins.
The problem: UARTS on max3109 seems to work fine - both rs485 are transmitting data, but not reciving. Problem is that RTS is always at 0V level...
In UARTs from am3352 I am using in device tree the following property: "linux,rs485-enabled-at-boot-time". But adding it to main max310x_0 node is not giving any effect - this node is the expander node (containing 2 UARTs and gpio-controller), not the UART itself.
My idea is that I need to add a child-nodes for each UART and in it place the property "linux,rs485-enabled-at-boot-time". But I don't have a clue how to do it. I tried something like this:
&spi1 {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&spi1_pins>;
num_cs = <1>;
cs-gpios = <&gpio2 17 0>;
ti,pindir-d0-out-d1-in;
max310x_0: max0#0 {
compatible = "maxim,max3109";
reg = <0>;
spi-max-frequency = <24000000>;
clocks = <&clk1m8>;
clock-names = "xtal";
interrupt-parent = <&gpio2>;
interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
gpio-controller;
#gpio-cells = <2>;
clk1m8: clk1m8 {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <1843200>;
};
ttyMAX0 {
linux,rs485-enabled-at-boot-time;
};
ttyMAX1 {
linux,rs485-enabled-at-boot-time;
};
};
};
but it didn't worked.
My question: How am I supposed to add those child-nodes (if that's the proper way) and what should I place in them to make RTS work?
EDIT:
after sawdust suggestion it seems it's impossible to add rs485 mode in device tree.
So I tried to add this functionality to device tree and I think I'm starting to understand how things work down in here. To start with something I'm printing port.flags value to dmesg and it seems my little insertion works (a bit) - it changes the value depending on presence of linux,rs485-enabled-at-boot-time parameter in device tree.
Here is the code I have inserted:
if (of_property_read_bool(dev->of_node, "linux,rs485-enabled-at-boot-time"))
s->p[i].port.flags |= SER_RS485_ENABLED;
printk("s->p[i].port.flags is: %d\n",s->p[i].port.flags);
The value of port.flags toggles from 134225920 to 134225921 depending on presence of linux,rs485-enabled-at-boot-time.
but the RTS pin still have constant 0V on my oscilloscope...
I'm trying to figure out if SER_RS485_RTS_ON_SEND and SER_RS485_RTS_AFTER_SEND have something to do with this, but I'm prete sure it's only for reverting RTS signal.
After few attempts IOCTL was the best and easiest solution. Here is some example code that helped me much. https://gist.github.com/amarburg/07564916d8d32e20e6ae375c1c83a995
It's basic example how to turn RS485 mode on and off using IOCTL and read it's current mode. Works with both CPUs internal UARTS and MAX3109.

Device interfacing using SMBus on Beaglebone Black

I am using ADM1032ARMZ-2R temperature sensor (as a beginner I am not allowed to post more than 2 links here, I have already posted 2 links for the images below - For datasheet please google ADM1032ARMZ-2R) with Beaglebone Black Rev C having pre-installed Debian (kernel - 3.8.13) . The datasheet of ADM1032 says that chip is available for communication at address 0x4D via SMBus Protocol. I have never worked on SMbus before but found that I2C is compatible with SMBus for 100 KHz and less. I tried doing following things
I wrote a device tree overlay. It looks like following (I have kept the frequency as 100 KHz)
// Device Tree Overlay for I2C1 uses Pins P9.17(SCLK) & P9.18(SDA)
/dts-v1/;
/plugin/;
/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";
part-number = "BBB-I2C1-4D";
version = "00A0";
exclusive-use =
"P9.18", /* i2c1_sda */
"P9.17", /* i2c1_scl */
/* the hardware ip uses */
fragment#0 {
target = <&am33xx_pinmux>;
__overlay__ {
bb_i2c1_pins: pinmux_bb_i2c1_pins {
pinctrl-single,pins = <
0x158 0x72 /* spi0_d1.i2c1_sda, SLEWCTRL_SLOW | INPUT_PULLUP | MODE2 */
0x15c 0x72 /* spi0_cs0.i2c1_scl, SLEWCTRL_SLOW | INPUT_PULLUP | MODE2 */
>;
};
};
};
fragment#1 {
target = <&i2c1>;
__overlay__ {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&bb_i2c1_pins>;
clock-frequency = <100000>;
#address-cells = <1>;
#size-cells = <0>;
/* adding adm1032 as i2c child device on the bus here */
tempsense: tempsense#4d {
compatible = "onsemi,adm1032";
reg = <0x4d>;
};
};
};
};
Compiled this file, copied the resultant .dtbo file in the /lib/firmware directory and successfully inserted it as a virtual cape in the /sys/devices/bone_capemgr.9/slots using echo command. It looks like this
I tried to observe the correctness of the above work using the following command
dtc -f -I fs /proc/device-tree | less
Intended things are happening and it looks like this (Please note that, for i2c1, the "ti,hwmods" field in the image shows "i2c2", but its actually i2c1 so please don't worry about it. I have read about it made sure that whatever it's showing is correct)
Now I am trying to do
i2cdetect -r 1
But I am not able to detect anything
at 0x02, there is a Status register available for reading
i2cget -y -f 0x4d 0x02
I get Read failed response
Where am I going wrong ? Please help.

Resources