I have a custom i.MX6 board, and I want to turn on a particular GPIO.
From the schematic, the GPIO pin is connected to KEY_COL2 pad, and the KEY_COL2 has the following options.
So, I have to export the following GPIO as per the calculation:
linux gpio number = (gpio_bank - 1) * 32 + gpio_bit
gpio number = ( 4 - 1 ) *32 +10 = 106
When I run the following command, i get the error:
# echo 106 > /sys/class/gpio/export
sh: write error: Device or resource busy
What can be the issue, am i missing anything...
After looking at the device tree, this particular GPIO was used by some other device, hence the error.
You can find the GPIO's in use with the following commands:
mount -t debugfs none /sys/kernel/debug
cat /sys/kernel/debug/gpio
Related
I am using olimex 3188 board and am trying to access gpios. When I attempt : ls -l /sys/class/gpio I get :
export
gpiochip160
gpiochip192
gpiochip224
gpiochip256
unexport
cat /sys/class/gpio/gpiochip160/ngpio returns 32
cat /sys/class/gpio/gpiochip160/label returns gpio0
cat /sys/class/gpio/gpiochip192/label returns gpio1
and so on until gpio3
I have read and understood what each block consists of, but for example I want to access pin : GPIO0_B4. Where does this pin belong?
Good day,
I am currently working on a project where PCIe SSDs are constantly being swapped out and tested through benchmark programs such as VDBench and Iometer. The problem I face right now, which is only on the Linux side (got it working fine on windows), is that if the drives were not on at initial boot-up, they never appear under GParted or Disks. Here's what I have done:
Cold boot, PCIe Add-in-card SSD is off. It is then powered on through a pass through card that is logically controlled to make sure power and shorts are not an issue.
I turn the device on, then run:
sudo sh -c "echo 1 > /sys/bus/pci/rescan"
Performing a
lspci -tv
The device shows with no issues in the tree. When I check under Disks however, it is not there.
I have tried a bunch of different commands with none of them seeming to help me. I have tried
partprobe
Which did not do anything. and:
sudo sh -c "echo 1 > /sys/bus/pci/devices/0000:82:00.0/remove"
Followed up another rescan:
sudo sh -c "echo 1 > /sys/bus/pci/rescan"
As well as:
sudo sh -c "echo 1 > /sys/bus/pci/devices/0000:82:00.0/enable"
Still nothing. Also ran:
dmesg
Which shows, amongst other things:
[ 68.128778] pci 0000:82:00.0: [8086:0953] type 00 class 0x010802
[ 68.128797] pci 0000:82:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]
[ 68.128820] pci 0000:82:00.0: reg 0x30: [mem 0x00000000-0x0000ffff pref]
[ 68.133398] pci 0000:84:00.0: [1c58:0003] type 00 class 0x010802
..............................
[ 68.141751] nvme 0000:82:00.0: enabling device (0100 -> 0102)
..............................
I do see a lot of fails in dmesg for other addresses, such as:
[ 1264.718446] pcieport 0000:03:04.0: BAR 14: no space for [mem size 0x00400000]
[ 1264.718448] pcieport 0000:03:04.0: BAR 14: failed to assign [mem size 0x00400000]
[ 1264.718451] pcieport 0000:03:04.0: BAR 13: no space for [io size 0x1000]
[ 1264.718453] pcieport 0000:03:04.0: BAR 13: failed to assign [io size 0x1000]
Although I have a feeling that those are unrelated to what I am doing, although I'd be happy for someone to prove me wrong.
So, after all of these attempts, does anyone know if there is a way (or if it is even possible) to scan for this PCIe Add-in NVMe SSD and be able to use it without rebooting? I also took a look at some of the threads for other HDDs that reference a rescan for sata based drives, but this is NOT that, so referencing that won't help either.
Thanks in advance.
I ran into the same issue benchmarking nvme PCIE passthrough with QEMU / Proxmox.
First take note of the driver in use:
lspci -nnk -s '0000:82:00.0'
It should say
Kernel driver in use: vfio-pci
Now unbind the driver, then reprobe:
echo '0000:82:00.0' > /sys/bus/pci/drivers/vfio-pci/unbind
echo '0000:82:00.0' > /sys/bus/pci/drivers_probe
Check the driver again with:
lspci -nnk -s '0000:82:00.0'
Kernel driver in use: nvme
lsblk should now show the drive. Found the procedure here
I tried doing that to save time which is used by rebooting. The PCI device driver at that time was dodgy at best about successfully rescanning and getting all its ducks in a row. The device was an FPGA presenting a proprietary interface device for a device driver I was developing. That was with kernel 2.6.30-something tried around March 2014. My (substandard, but acceptable) solution was to reboot the system.
I'm trying to communicate with a Di245 through its Virtual COM driver (VCD) in Linux (pdf) and I'm having a strange issue. Internally, an FTDI chipset is used by this device (FT232BL).
Attaching the device by itself isn't registered as a VCD, so I do the following:
sudo modprobe usbserial vendor=0x0683 product=0x2450
which results in the following dmesg message:
usbserial: USB Serial support registered for generic
usbserial_generic 3-3:1.0: The "generic" usb-serial driver is only for testing and one-off prototypes.
usbserial_generic 3-3:1.0: Tell linux-usb#vger.kernel.org to add your device to a proper driver.
usbserial_generic 3-3:1.0: generic converter detected
usb 3-3: generic converter now attached to ttyUSB0
and I get the /dev/ttyUSB0 device as promised. So far, everything seems ok.
However, if I open the port in my code, I get a bunch of 1` from it (alternating 1 and `). Trying with screen:
screen /dev/ttyUSB0 115200
I continuously receive 1`. This is definitely not something the device is sending and oddly enough, if I put a random baudrate, I keep getting the same thing.
Is this a way some error is being reported? What could be triggering this behavior and how can I address it?
The solution was the following:
# modprobe usbserial vendor=0x0683 product=0x2450
# modprobe ftdi_sio
# echo "0683 2450" >> /sys/bus/usb-serial/drivers/ftdi_sio/new_id
This way, the ftdi_sio driver knows which vendor/product to provide VCD for. The following udev rule (say, 99-di245.rules) can automate this:
ACTION=="add", ATTRS{idVendor}=="0683", ATTRS{idProduct}=="2450", RUN+="/sbin/modprobe ftdi_sio" RUN+="/sbin/modprobe usbserial vendor=0x0683 product=0x2450" RUN+="/bin/sh -c 'echo 0683 2450 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id'"
It is installed with:
$ sudo cp 99-di245.rules /etc/udev/rules.d
$ sudo udevadm control --reload
I have a CORE9G25-CON (256MBRAM) (http://armdevs.com/core9g25.html) device with embedded linux installed on it.
The version of linux is:
# uname -or
3.6.9 GNU/Linux
# cat /etc/os-release
NAME=Buildroot
VERSION=2012.11.1-dirty
ID=buildroot
VERSION_ID=2012.11.1
PRETTY_NAME="Buildroot 2012.11.1
The device is equipped with USB host connector in which I connected an USB-AUDIO interface
The USB interface is recognize by the system
# cat /proc/asound/cards
0 [Device ]: USB-Audio - USB PnP Sound Device
C-Media Electronics Inc. USB PnP Sound Device at usb-at91-1, full speed
# cat /proc/asound/devices
0: [ 0] : control
16: [ 0- 0]: digital audio playback
24: [ 0- 0]: digital audio capture
33: : timer
# ls /dev/snd
controlC0 pcmC0D0c pcmC0D0p timer
I would like to handle the AUDIO interface by using ALSA but this is the error shown on the console by using the simple command aplay -l
# aplay -l
**** List of PLAYBACK Hardware Devices ****
ALSA lib control.c:739:(snd_ctl_open_noupdate) Invalid CTL hw:0
aplay: device_list:226: control open (0): No such file or directory
aplay: conf.c:3095: snd_config_update_free: Assertion `update->count > 0 && update->finfo' failed.
Aborted
I googled for about a week trying to fix the problem but, up to now, i didn't find any solution.
Could you help me to fix the problem ?
Had you other similar experience about it ?
Thank you very much for your help and cooperation
best regards
What does your alsa.conf look like ? do this
locate alsa.conf
typically found at
/usr/share/alsa/alsa.conf
do a google on
audio sound alsa Invalid CTL hw:0
this might get you on the right path
#alsa.conf minimal configuration
ctl.hw {
#args [ CARD ]
#args.CARD {
type string
}
type hw
card $CARD #with 0 alsamixer work, with $CARD alsamixer lend to invalid argument
}
Trying to solve this problem (ttyUSB0 that works properly than stop working after about 1hr)I'm thinking on if disconnecting and reconnecting the usb device could be a good fix.
So, it is possibile to cut down power to the USB device and repower it programmatically (bash)?
# lsusb -t
1-1:1.0: No such file or directory
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
|__ Port 1: Dev 2, If 0, Class=vend., Driver=, 12M
|__ Port 1: Dev 2, If 1, Class=vend., Driver=cp210x, 12M
On am335x, kernel 3.2.0, ubuntu core armhf.
[ 1.784332] usb 1-1: cp210x converter now attached to ttyUSB0
At the moment I need a complete power cycle to have ttyUSB0 back.
This is the solution:
Find the identity of your usb device.
# tree /sys/bus/usb/drivers/cp210x/
/sys/bus/usb/drivers/cp210x/
|-- 1-1:1.1 -> ../../../../devices/platform/omap/musb-ti81xx/musb-hdrc.1/usb1/1-1/1-1:1.1
|-- bind
|-- module -> ../../../../module/cp210x
|-- remove_id
|-- uevent
-- unbind
So 1-1:1.1 is the identifier of my ttyUSB0(it can be discovered also via dmesg).
Then, disconnect the device (as root):
# echo -n "1-1:1.1" > /sys/bus/usb/drivers/cp210x/unbind
reconnect it
# echo -n "1-1:1.1" > /sys/bus/usb/drivers/cp210x/bind
At this point I had the same device but with a different name, it was now ttyUSB1 instead of ttyUSB0.
- To avoid this I added a new rule in /etc/udev/rules.d/ by creating a new file named 99-usb-serial.rules with this line:
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea70", ATTRS{serial}=="002DCFAF", SYMLINK+="sameName", MODE:="0666"
where idVendor, idProduct and serial must be the values of your device. This rule will create a new device called sameName linked to the ttyUSB* device normally generated from the OS.
As #Robert Harvey Said,
You first need to find our driver that will help you 'unplug and plug' the usb. Type: ls /sys/bus/usb/drivers which should print something like this: btusb ftdi_sio hub usb usbfs usbhid usbserial_generic uvcvideo. These, are all the drivers for each usb device. Now, lets say mine is ftdi_sio, which is a device i use to program my arduino (atmega328p chip). I am not sure how Your/other usb devices name themselves there. Like, i dont know which of these is my mouse.
Now, you can see the driver's commands using:
ls /sys/bus/usb/drivers/ftdi_sio/, which will print something like: 1-4:1.0 bind module uevent unbind, Where 1-4:1.0 is the device's characteristic code, and the bind and unbind command, which are the 'plug' and 'unplug' command respectively.
Now, if i want to unplug programatically the ftdi usb port, i will type:
echo -n "1-4:1.0" > /sys/bus/usb/drivers/ftdi_sio/unbind
and, to plug it again:
echo -n "1-4:1.0" > /sys/bus/usb/drivers/ftdi_sio/bind
Now, we can combine all the commands together, with a ';':
echo -n "1-4:1.0" > /sys/bus/usb/drivers/ftdi_sio/unbind ; echo -n "1-4:1.0" > /sys/bus/usb/drivers/ftdi_sio/bind