I did the following steps in order to use spidev in Linux- kernel 3.14.28 compiled on arm imx6Q (SMARC board, by Yocto-Project):
In kernel configuration, I enabled SPIDEV: CONFIG_SPI_SPIDEV=y.
In device tree, I added the following lines:
&smarc_spi0 {
spidev#1 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "linux, spidev";
spi-max-frequency = <20000000>;
reg = <1>;
};
};
I compiled my Linux successfully, and still can't see /dev/spidev0.1 appear in /dev folder.
Any idea?
I found out the problem: compatible string wasn't accurate..
I had extra space between "linux," and "spidev"..
The appropriate way is:
compatible = "linux,spidev";
Related
I have a I.MX 8M Plus chip on my PCB and I need to write to it a MAC address from Linux user space.
The Linux kernel uses NVMEM driver(drivers/nvmem/ocotp.c) rather than FSL_OTP driver. The dts include the ocotp device support.
ocotp: efuse#30350000 {
compatible = "fsl,imx8mp-ocotp", "fsl,imx8mm-ocotp", "syscon";
reg = <0x30350000 0x10000>;
clocks = <&clk IMX8MP_CLK_OCOTP_ROOT>;
/* For nvmem subnodes */
#address-cells = <1>;
#size-cells = <1>;
imx8mp_uid: unique-id#420 {
reg = <0x8 0x8>;
};
cpu_speed_grade: speed-grade#10 {
reg = <0x10 4>;
};
eth_mac1: mac-address#640 {
reg = <0x90 6>;
};
eth_mac2: mac-address#650 {
reg = <0x96 6>;
};
The nvmem in the sysfs entry is /sys/devices/platform/soc#0/{SOME_ID}.bus/{SOME_ID}.ocotp-ctrl/imx-ocotp0/nvmem
The patch mentioned in the https://community.nxp.com/t5/i-MX-Processors/OCOTP-write-support-on-i-mx8m/m-p/825028?commentID=1161... is already present.
Could you please let me know how to write the MAC address from userspace (eg. Aa:Bb:Cc:Dd:Ee:Ff).I need to assign mac addresses to mac1(mac-address#640) and mac2(mac-address#650) I dont want to write the MAC address from uboot or using UUU.
Hello i am currently working with the beaglebone black and i am trying to compile a device tree overlay which is used to allocate memory, however i am getting several warnings from the device tree compiler that preventing the compiler from producing a working dtbo file. My kernel version is 4.19.94-ti-r42 and i am running the Debian 10 buster distro. The dts file is shown below:
/dts-v1/;
/plugin/;
/* Reserve 256kB DDR memory for the ping/pong buffers */
/{
__overlay__ {
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
pruadc_reserved: pruadc_reserved#0x9ffc0000 {
reg = <0x9ffc0000 0x00040000>;
no-map;
status = "okay";
};
};
};
};
I then compile the dts file with command below:
dtc -W no-unit_address_vs_reg -O dtb -o shared_ddr.dtbo -b 0 -# shared_ddr.dts
After compiling a dtbo file is produced but several warnings are shown, the dtbo file is not functional. The warnings are shown below:
shared_ddr.dtbo: Warning (ranges_format): /__overlay__/reserved-memory:ranges: empty "ranges" property but its #address-cells (1) differs from /__overlay__ (2)
shared_ddr.dtbo: Warning (avoid_default_addr_size): /__overlay__/reserved-memory: Relying on default #address-cells value
shared_ddr.dtbo: Warning (avoid_default_addr_size): /__overlay__/reserved-memory: Relying on default #size-cells value
shared_ddr.dtbo: Warning (avoid_unnecessary_addr_size): Failed prerequisite 'avoid_default_addr_size'
shared_ddr.dtbo: Warning (unique_unit_address): Failed prerequisite 'avoid_default_addr_size'
Any help with fixing these warnings will be greatly appreciated, thank you. If any other info is needed let me know.
First I must to tell you, I am not really from electronics background, I have very rough knowledge about Linux drivers, I2C, touch screens, etc.
Problem background
My Wandboard was previously working with Fusion 7 touch display worked with Prism touch screen driver, already provided by Wandboard.
As per my new requirement, I have got Ilitek touch screen which I am trying get it working with my Wandboard dual (i.MX6-Cortex-A9, Linux Kernel:3.0.35).
I got following Ilitek touch screen driver files under folder ilitek_limv3_0_9.
ilitek_lim.c
ilitek.h
ilitek_update.c
ilitek_i2c.idc
I compiled the driver into Linux kerenl as a built-in module, tried to run on the board but failed. The driver doesn't appear in /dev/input.
I debuged the kerenl code a bit, and found that the code doesn't reach to driver's probe function, instead it fails in device binding (i2c device registration). Just then I come to know about Device tree.
I looked into following dts files (which I believe my Wandboard is using), putting little i2c configuration present in the files here.
imx6qdl.dtsi
i2c1: i2c#021a0000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx6q-i2c", "fsl,imx21-i2c";
reg = <0x021a0000 0x4000>;
interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_I2C1>;
status = "disabled";
};
i2c2: i2c#021a4000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx6q-i2c", "fsl,imx21-i2c";
reg = <0x021a4000 0x4000>;
interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_I2C2>;
status = "disabled";
};
i2c3: i2c#021a8000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx6q-i2c", "fsl,imx21-i2c";
reg = <0x021a8000 0x4000>;
interrupts = <0 38 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_I2C3>;
status = "disabled";
};
imx6qdl-wandboard.dtsi
&hdmi {
ddc-i2c-bus = <&i2c1>;
status = "okay";
};
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
};
&i2c2 {
clock-frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c2>;
status = "okay";
codec: sgtl5000#0a {
compatible = "fsl,sgtl5000";
reg = <0x0a>;
clocks = <&clks 201>;
VDDA-supply = <®_2p5v>;
VDDIO-supply = <®_3p3v>;
};
};
I see dts note entry for sgtl5000 which is audio codec which then appears as /dev/input/event0. But I don't find any entry for 'prism' driver, which actually runs perfectly on the board. Neither dts files nor board-files have entry for 'prism' driver. But I am sure it's using 'device-tree' approach.
Questions
As my Wandboard works fine with 'prism' driver and touch device, why I don't see device node entry for 'prism' in dts files ?
Is there any other way for 'i2c device registration' other than 'device-tree' and 'earlier board-file' approach ?
How could I get past with ilitek touch driver not getting i2c-matched/registered problem ?
Thanks in advance.
I am trying to use AD5628 Digital to analog converter on my raspberry Pi 3 board . I have enabled the driver for that (http://lxr.free-electrons.com/source/drivers/iio/dac/ad5064.c) in the Yocto kernel .
But when i opened the path /sys/bus/iio/devices/
Mentioned in (https://wiki.analog.com/resources/tools-software/linux-drivers/iio-dac/ad5446) i am not getting any device0.
I got to know that it is a Device tree issue , So i refereed some web sites (https://patchwork.kernel.org/patch/7374261/) and came to know that i need to add the following Device tree details
ad5628-1#4 {
compatible = "adi,ad5628-1";
reg = <4>;
spi-max-frequency = <10000000>;
adi,use-external-reference;
};
But i am not able to find where to add this information in the linux kernel . and how to enable the device tree for this so that my DAC device should be detected by Linux .
Any help regarding this issue will be greatly appreciated
How is the DAC connected to your RPi board ? (SPI/i2c.. ??), so you need to add the dac as part of that device.
For example, in the link which you mentioned the dac is connected to the SPI, so similarly on those lines you need add the DT nodes and also enable the driver in the kernel.
axi_spi_1: spi#42040000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "xlnx,axi-spi-1.02.a", "xlnx,xps-spi-2.00.a";
...
ad5446#0 {
compatible = "adi,ad5446";
reg = <0>;
spi-max-frequency = <1000000>;
spi-cpha;
spi-cpol;
vcc-supply = <&dac_vcc>;
};
};
I have used Yocto to create a small linux image for the Beaglebone Black. I think I have most everything working like I want it, except I need access to UARTs 2 and 4. When I was using the standard Debian image, I did this with device tree overlays and capemgr. However, I found that the kernel built with Yocto doesn't have capemgr.
My options seem to be:
get the kernel to build with capemgr, or
modify the device tree file with the necessary changes.
Option 2 seems much easier.
The device tree overlays for the UARTs are here and here. I have gone about trying to include those in a couple ways.
I decompiled the device tree blob I had been using and tried to
include these files from there.
I downloaded the full set of dts files and tried to include the
UART device tree overlays in am335x-boneblack.dts.
Both approaches yield an error something like this:
Error: am335x-boneblack.dts:1.1-2 syntax error
FATAL ERROR: Unable to parse input tree
However, I noticed that I get a similar error when trying to compile am335x-boneblack.dts even without modifying it, so I'm likely not even doing that right. (Using the command dtc -I dts -O dtb -o result.dtb am335x-boneblack.dts)
Obviously I don't know what I'm doing. I suspect the device tree overlays have to be modified in some way to be used in the way I'm trying to use them. Or maybe I'm not doing the include right (just adding a #include to the top of the file).
Does anybody have any ideas what I might be doing wrong? Is what I'm trying to do even possible?
So I got this working by taking my device tree blob, decompiling it, and merging in sections from the device tree overlay files, and recompiling. I realized I needed uarts 1 and 2 instead of 2 and 4, so this is slightly different than my original problem.
To decompile the device tree blob:
dtc -I dtb -O dts -o am335x-boneblack.dts am335x-boneblack.dtb
I used the existing uart0 as an example to show me the right sections to work in.
I added a section for uart1 and uart2 in the pinmux section under the section for uart0. It now looks like this:
pinmux_uart0_pins {
pinctrl-single,pins = <0x170 0x30 0x174 0x0>;
linux,phandle = <0x27>;
phandle = <0x27>;
};
bb_uart1_pins: pinmux_bb_uart1_pins {
pinctrl-single,pins = <
0x184 0x20 /* P9.24 uart1_txd.uart1_txd OUTPUT */
0x180 0x20 /* P9.26 uart1_rxd.uart1_rxd INPUT */
>;
};
bb_uart2_pins: pinmux_bb_uart2_pins {
pinctrl-single,pins = <
0x150 0x21 /okay* spi0_sclk.uart2_rxd | MODE1 */
0x154 0x01 /* spi0_d0.uart2_txd | MODE1 */
>;
};
Then later, the serial sections need to be enabled and told what pins to use. I modified existing uart sections, and it now looks like this:
serial#44e09000 {
compatible = "ti,omap3-uart";
ti,hwmods = "uart1";
clock-frequency = <0x2dc6c00>;
reg = <0x44e09000 0x2000>;
interrupts = <0x48>;
status = "okay";
dmas = <0x26 0x1a 0x26 0x1b>;
dma-names = "tx", "rx";
pinctrl-names = "default";
pinctrl-0 = <0x27>;
};
serial#48022000 {
compatible = "ti,omap3-uart";
ti,hwmods = "uart2";
clock-frequency = <0x2dc6c00>;
reg = <0x48022000 0x2000>;
interrupts = <0x49>;
status = "okay";
dmas = <0x26 0x1c 0x26 0x1d>;
dma-names = "tx", "rx";
pinctrl-names = "default";
pinctrl-0 = <&bb_uart1_pins>;
};
serial#48024000 {
compatible = "ti,omap3-uart";
ti,hwmods = "uart3";
clock-frequency = <0x2dc6c00>;
reg = <0x48024000 0x2000>;
interrupts = <0x4a>;
status = "okay";
dmas = <0x26 0x1e 0x26 0x1f>;
dma-names = "tx", "rx";
pinctrl-names = "default";
pinctrl-0 = <&bb_uart2_pins>;
}
To recompile the device tree:
dtc -I dts -O dtb -o am335x-boneblack.dtb am335x-boneblack.dts
In short, I managed to get this working despite having little to no idea how device trees work.
I also needed to disable hdmi which I did by setting status equal to "disabled" in the hdmi section.