I need to write a script that controls and checks the gpio states.
I have been trying for a while to find a way to do it, but I didn't succeed.
Here is for the details :
I use an at91sam9260 board with a Linux kernel 2.6.27 embedded in it.
I see the /dev/gpio device
I tried some commands like cat /dev/gpio OR echo 1> /dev/gpio but it did not give me any result ( except an error message for the first command)
I also tried to create /dev/gpio0 .. to /dev/gpio31 (with the makedev command before recompiling the CRAMFS filesystem, but I did not get more results.
Does someone know how to check these gpio states and set/clear some of them ?
More generally, Is there an easy way to find out the proper shell commands for a particular device just by looking at the driver source files ?
If your kernel has sysfs support you can access and control the gpio pins through the interface in /sys/class/gpio. See the sysfs section of the kernel document in Documentation/gpio.txt.
I have used at91sam9260. You can set/unset the gpio pins using sysfs interface.
for ex. go to: cd /sys/class/gpio and then "echo 2 > export" and then set the directions of gpio pins to input(in)/output(out) by "echo in > direction" and then you can read the value from "value" file by "cat value"
Check /sys/kernel/debug/pinctrl/ directory for verbose GPIO info.
Related
I am reading source code under Linux and reach this function:
ioctl (fd, TIOCGDEV, &devnum)
But I don't find the document about the macro TIOCGDEV from man page, what does this macro mean ?
"/* Get real dev no below /dev/console */"
"The TIOCGDEV ioctl is a hack written to allow bootup messages to be display both on the screen and also to be logged"
"Without the real device to which /dev/console is connected, blogd can not work."
https://www.mail-archive.com/pld-cvs-commit#lists.pld-linux.org/msg230185.html
https://elixir.bootlin.com/linux/latest/source/drivers/tty/tty_io.c#L2747
https://arstechnica.com/civis/viewtopic.php?f=16&t=477204
https://opensuse.opensuse.narkive.com/DRN6tZW3/sle-tiocgdev-patches-for-new-kernels
I believe nowadays we have journald from systemd.
I am running ubuntu 18.04, kernel 4.19.94-ti-r36, on a a beaglebone black. I am connected to ssh, and am trying to adjust the boot configuration of the GPIO pins. After boot, I am able to change and query individual GPIO configurations with the "config-pin" command, which is useful for experimentation. But I would like to change all the default GPIO configuration on boot, which this tool does not appear to do.
I found this tutorial on using a device overlay to achieve this here:
http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/
but I am missing the "bone_capemgr.8" directory. I googled this issue and was directed to this page, which says that device tree overlays are now deprecated, and to use u-boot overlays instead:
https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays.2C_which_got_loaded
I read through the article, and googled around, but I haven't found anything on how to actually use a u-boot overlay to change the configuration of the GPIO pins on boot.
Does anyone know how to do this, or know where I might find a good resource to this effect?
Thanks!
Edit: here are the steps I think I need to take, based on De Funct's answer:
install bb.org-overlays found here, https://github.com/beagleboard/bb.org-overlays, with:
sudo apt install bb-cape-overlays
create a .dts file with the correct configuration
compile .dts-->.dtbo file:
dtc -O dtb -o out_file.dtbo -b 0 -# in_file.dts (or something similar?)
adjust this line in /boot/uEnv.txt file to reference compiled dts
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/.dtbo
something to do with boot images (?)
Questions:
what does searching "in the kernel" mean? how would I do this?
for the actual .dts file, I looked around and found this as a starting point:
https://github.com/derekmolloy/boneDeviceTree/blob/master/overlay/DM-GPIO-Test.dts My plan is to modify/extend lines 29-33 to change the boot configuration of all relevant pins. The second hex number is the pin mode I'm trying to change; that makes sense. The first hex number looks like it somehow corresponds to pin number, but I'm not sure how? for example, 0x078-->P9.12,0x184-->P9.24, etc.
when/where does making an image come into play? what about making two different partitions? I didn't follow that part
to use the uboot-overlays, which is a given for most concepts with GPIO pins on the BBB, one would have to install bb.org-overlays which are found here, https://github.com/beagleboard/bb.org-overlays, and to understand Device-Tree Specifications.
https://github.com/beagleboard/BeagleBoard-DeviceTrees will help you, too.
The Device Tree specification can be found here: https://www.devicetree.org/
In the kernel, you can search the docs. and kernel for specific, already-made device tree ideas and files.
Also, it is as simple as creating your dts file, compiling it, and putting it in the correct space on the BeagleBone Black in /boot/uEnv.txt.
For instance, if I had a specific .dtbo that I compiled from my .dts file(s), I would simply put it in the /boot/uEnv.txt file under this heading...
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/<file0>.dtbo
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays should explain the ideas I am listing.
Oh! Also, when creating your image, one would have to create the two partitions, one for booting and the other for the actual OS/filesystem.
Once this is completed, one would have to install the file uEnv.txt in the /boot dir. by simply making the file in a text editor, saving it, and placing it in the system before compilation via make menuconfig or whatever you are using to install the boot partition and OS partition.
If you need exact placements of the files in the kernel to search under for the .dts, .dtb, and .dtbo files, ask away. I have had complications with this before and lacking understanding, I have been a drift. Luckily, there is a long list of ideas but one needs to make them accessible in the correct order.
Also: https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black are some ideas on how to start the image factory of making things available for the BeagleBone Black.
Edit: here are the steps I think I need to take, based on De Funct's answer:
install bb.org-overlays found here, https://github.com/beagleboard/bb.org-overlays, with:
git clone https://github.com/beagleboard/bb.org-overlays
create a .dts file with the correct configuration
Your configuration of the .dts file works too...(supposedly as I have not seen it).
compile .dts-->.dtbo file:
dtc -O dtb -o out_file.dtbo -b 0 -# in_file.dts (or something similar?)
Not this idea. Although, compiling using the device-tree-compiler is an option, I say use their build script w/ their Makefile.
So, try ./install.sh
adjust this line in /boot/uEnv.txt file to reference compiled dts
###Overide capes with eeprom
uboot_overlay_addr0=/lib/firmware/your_newly_added_file.dtbo
...
Also and excuse me if this does not work, you can try with the BeagleBoard-DeviceTrees link I provided.
In that one, you would simply place the correct file, your .dts file, in the /src/arm/ directory, and go back to the BeagleBoard-DeviceTrees/ dir. to perform the make command.
It will perform all the necessary .dts to .dtb to .dtbo file operations.
This is the /boot/uEnv.txt file I have currently...
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
uname_r=4.19.94-ti-r59
#uuid=
#dtb=
###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
uboot_overlay_addr0=/lib/firmware/BB-UART2-00A0.dtbo
#uboot_overlay_addr1=/lib/firmware/<file1>.dtbo
#uboot_overlay_addr2=/lib/firmware/<file2>.dtbo
#uboot_overlay_addr3=/lib/firmware/<file3>.dtbo
###
###Additional custom capes
#uboot_overlay_addr4=/lib/firmware/<file4>.dtbo
#uboot_overlay_addr5=/lib/firmware/<file5>.dtbo
#uboot_overlay_addr6=/lib/firmware/<file6>.dtbo
#uboot_overlay_addr7=/lib/firmware/<file7>.dtbo
###
###Custom Cape
#dtb_overlay=/lib/firmware/<file8>.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
###
###PRUSS OPTIONS
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_rproc (4.19.x-ti kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
###pru_uio (4.14.x-ti, 4.19.x-ti & mainline/bone kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
###
See where the file states #dtb=? That is section where the .dtb needs to be located and uncommented by removing the hash symbol.
Also, under that particular section of the file, there are u_boot-overlay sections. You can now add your .dtbo files in those particular slots.
I am building some kind of kiosk system and I bought this USB DIY keyboard for it: https://www.amazon.com/gp/product/B07QPXQQ7L
This allows me to have a lot of buttons and they behave like keyboard keys.
I'm writing a program (Perl) that will take the input from that keyboard and do things based on that.
The problem is that I need to have the rest of the system (both X and the TTYs) ignore that keyboard so that it won't type random things in the terminal or in the window manager. In other words, the system should disregard it but the device itself must still be available in /dev/input/...
I don't need a real keyboard to control the machine because I connect via VNC and SSH.
Bonus points if you know how to read from a /dev/input/... keyboard and end up with letters typed just like with STDIN in a terminal.
Thanks!
I found the solution here where someone wanted the exact same thing in the case of a barcode reader:
https://serverfault.com/questions/385260/bind-usb-keyboard-exclusively-to-specific-application/976557#976557
SUBSYSTEM=="input", ACTION=="add", ATTRS{idVendor}=="xxxx", ATTRS{idProduct}=="yyyy", RUN+="/bin/sh -c 'echo remove > /sys$env{DEVPATH}/uevent'"
ACTION=="add", ATTRS{idVendor}=="xxxx", ATTRS{idProduct}=="yyyy", SYMLINK+="diykeyboard"
And then replace xxxx and yyyy by the Vendor and Product ID as found in lsusb. So in my case 1c4f and 0002:
Bus 001 Device 003: ID 1c4f:0002 SiGma Micro Keyboard TRACER Gamma Ivory
The udevadm control --reload thing didn't do it for me, I had to reboot.
Then in theory the data typed on the keyboard should be available at /dev/diykeyboard (the SYMLINK variable).
Now in my case unfortunately there are multiple events that match this vendor+product, and to match the right one I needed to add DEVPATH=="*:1.0/*", KERNEL=="event*" in the second line where it creates the SYMLINK. And then surprise it did not create the link in /dev so I had to do something dirty, create a link myself with ln:
SUBSYSTEM=="input", ACTION=="add", ATTRS{idVendor}=="1c4f", ATTRS{idProduct}=="0002", RUN+="/bin/sh -c 'echo remove > /sys$env{DEVPATH}/uevent'"
SUBSYSTEM=="input", ACTION=="add", ATTRS{idVendor}=="1c4f", ATTRS{idProduct}=="0002", DEVPATH=="*:1.0/*", KERNEL=="event*", RUN+="/bin/sh -c 'ln -sf /dev/input/$kernel /diykeyboard'"
(don't create the link in /tmp since udev happens before the mounting of /tmp at boot)
From there I can read from /diykeyboard (which usually points to /dev/input/event0) either with evtest which shows the keys typed, or directly with my program and then decoding the scancodes.
I am connected on my embedded device with the serial port and would like to start my custom binaries on boot and be able to see the output generated.
My /etc/inittab file contains:
console::respawn:/sbin/getty -L 115200 ttyAPP3 vt100
console::respawn:/usr/bin/mybinary
With this configuration, I can see the output of mybinary in the serial console but It is difficult/impossible to connect (insert login and password) to getty because of the interference of the output generated.
I tried to switch the output in inittab to another not used tty (tty10) like this:
console::respawn:/sbin/getty -L 115200 ttyAPP3 vt100
tty10::respawn:/usr/bin/mybinary
And now I can connect but how can I see the output generated to /dev/tty10 ?
I tried cat /dev/tty10 but nothing is shown.
I know the question is old, but it has no answers at all for crying out loud.
Remember that a TTY is both an output device and also an input device -- by cat'ing from it you're reading input from the terminal which means the keyboard, NOT the screen.
I don't know if there's a parallel in other *nixes, but Linux systems have /dev/vcsX and /dev/vcsaX character devices (nodes c,7,0+X and c,7,128+X respectively) for each /dev/ttyX device - these are mirrors of the data currently on the output of the TTY device (ie. the screen part of the TTY, not the keyboard part). These will give you what you're looking for. The vcsaX devices will give you a displaybyte+attributebyte pair (i.e. the foreground/background text colour -- see other references for more information on text attribute bytes) for each character on the screen, while the vcsX devices give only the displaybyte for each character. Of course it's a raw stream/dump so if the row and/or column count of your terminal doesn't match that of the the TTY you're dumping then you'll need to parse the data and reformat it to match.
tl;dr: use "cat /dev/vcs10"
Hope that helps.
In Ubuntu, we can select the output device of audio in sound preferences. But now I want to write a shell script, so I need to select the output device from the commandline.
You can first view your current default audio device by typing:
pactl stat
And with
pactl list
you can view all your devices.
And with this command
echo "set-default-sink alsa_output.Headset" | pacmd
you can set the default device.
But I found a much better source for this problem and a included little shell script for this problem here http://ubuntuforums.org/archive/index.php/t-1370383.html