I want to modify my linux kernel's (2.6.32) UART driver. I am using the standard uart driver for ttyS2 I dont know the exact files. The problem is Simple, setting and keeping a gpio pin high during transmission and while receving it must be low.
Which files should i refer to ? And any ideas about bitbanging gpio s from uart driver are wellcome...
Regards.
Try to understand how the Linux Serial Driver Layers are working and organized .
Determine which serial chip (driver) your device is using.
Hack the bit-banging GPIO into the low-lever driver.
OR:
Maybe you can abuse another signal line instead of a GPIO. If you operate your UART in RS485 mode, mostly the RTS behaves like you want -> high during transmission. I'm not sure if the rest of the communication would be rs232-compliant, but why not just try.
Related
(iMX6 SOC running Linux 3.0)
I need to run a few I2C transactions in my board_init function. I tried calling i2c_get_adapter, then i2c_transfer, those being available in kernel mode, but i2c_get_adapter returns NULL. It's already called imx6q_add_imx_i2c, which is a wrapper around platform_device_register_full, but that isn't enough.
I can manipulate GPIO in board_init by calling gpio_request to obtain access, and gpio_free at the end. Is there something analogous to those functions for i2c?
--- added details ---
I've got a LAN9500A USB 100Base-T Ethernet MAC connected to a LAN9303 3-port switch with a virtual PHY. The MAC has a GPIO reset line that has to be turned off before it will spring to life and enumerate on the USB. That's done in board_init because it's completely nonstandard, so we don't want to patch the stock driver to manipulate some GPIO that's not part of the device.
The problem I'm having is that even though the MAC is permanently attached to the VPHY, it's not noticing it's connected, and an "ip link show eth1" command shows NO-CARRIER. I found I can kickstart it by unmasking the VPHY's Device Ready interrupt via I2C, but I also have to mask it immediately, or I get infinite interrupts. That's not the right solution, but Microchip has been no help in showing me a better way. But we don't want to patch the MAC driver with code to fiddle with the PHY.
There is no PHY driver for this part, and the MII interface to the VPHY doesn't include any interrupt-related registers, so it must be done through I2C. Writing a PHY driver just to flip a bit on and off once seems a lot of trouble, especially for a newbie like me who's never written a driver before.
I can do it in Python in a startup script, but that, too, seems like a heavyweight solution to a lightweight problem.
That's a wrong approach. Board file supposed to register device drivers and pass important information to them, rather than act as a device driver itself. I'm not sure if what you're trying to do is even possible.
If you really need to extract something from your I2C device on a very early stage - do that in the bootloader and pass the data to kernel via cmdline (U-boot, by the way, has I2C support for a quite some time). Then later, kernel might do appropriate actions depending on what you have passed to it.
I have booted a ubuntu on a ZedBoard. I want to transfer data between fpga and linux. For example, I want to write or read a register from linux. What is best way for doing it? I have not any idea.
Thanx.
First of all, you need to specifically say what you want to do, for example. if you want to access the IO signals on the FPGA, you need to first add the GPIO module to your system, synthesize and implement it.
Then you use the Linux GPIO Driver to access the port as it is explained in this page:
Linux GPIO Driver
The GPIO driver fits in the Linux GPIO framework which is not a char
mode driver. Yet it does provide access to the GPIO by user space
through the sysfs filesystem. This allows each GPIO signal to be read
and written in similar manner to a char mode device. The interface is
somewhat documented in the kernel tree at Documentation/gpio.txt. The
following text is aimed to augment, not replace the existing
documentation.
For other, more complex interfaces you need to create your own driver or use one of the drivers that are available and modify it to fit your needs.
Does anyone know how to determine from the USB device descriptor or other USB descriptors if a USB device is HID or keyboard emulation? I'm looking to interface to a family of magtek magcard swipe readers and they can be configured to operate as HID or keyboard emulation. The magtek PID will tell me but what happens if someone plugs in a different manufacture? I'm looking for a univseral way of determining this. I'm using the libudev library to interface to my USB.
Also, does Linux have a universal routine to decode keyboard emulation scan codes. I've got my own look-up table which works fine but I was just wondering.
Steve
The only way you can tell what a device is, is by using the PID/VID of the USB device (and the Class, but I believe both modes are declared as HID-class devices anyway).
So, if you plug in a new manufacturer, you'll have to manually add support for it. From my experience (I did not use a magtek reader, but a tmsr33), no reader behave the same way in both HID or emulation mode. Generally speaking, I'd say it is better to use HID mode, as bytes exposed will need less conversion.
AFAICT, I went into the same trouble and I basically copy pasted the keycodes/keylayout from the kernel sources to my own code. If you prefer, you can link directly to the kernel's source code to get the tables.
https://github.com/MicahCarrick/magtek-pyusb
https://github.com/guyzmo/tmsr33-pyusb‎
HTH
Question
How, given the information udev passes to my kernel module (the block device path maybe), can I send SCSI commands to the block device? (yet have it function normally otherwise, meaning partitions are mounted, no data loss, etc)
What I'm Trying To Do
I have a USB mass storage device that has LEDs which are controlled via SCSI commands.
I would like to write an LED driver to provide /sys/class/leds/* entries for it.
The goal here is to have the device function normally (partitions mounted and functioning, etc) but also allow /sys/class/leds/* interactions that would send SCSI commands to control the LEDs.
It's easy to to send the SCSI commands I need in user space with sg_raw. But I need a kmod to provide /sys/class/leds/...
Essentially what I need is ioctl(). However, I understand it is generally a bad idea to call open(),ioct(),etc from within a kmod.
It can be achieved by some pseudo driver that emulates between USB & SCSI. I think what ever be your problem may achieved while you are accessing the USB device through SCSI.
These low level & mid level scsi drivers are defined.
I want to use rs485 placed on my card. I'm working on arm-linux and with pxa255 processor. I have already checked "serial.h" located in arm-linux tool chain but unfortunately i couldn't find the appropriate rs485 settings struct although it is supported in some other environments like cris. So now, do i have to write a low-level driver to enable rs485 or is there any other easier way to do this?
I'd recommend reviewing this page about Linux RS-485 support.
There seems to be quite a lot of confusion about serial ports with regards to RS485 mode support on Linux drivers. I think I might be able to shed some light answering this question.
First off, you should ask yourself: why do I want to activate RS485 support on my serial port? I don't know what development board or hardware you're using but be aware that most UARTs work with single-ended TTL levels only (5V or 3.3V levels). That means you won't be able to talk to RS485 devices directly because they only handle differential signals. If you want more details you can see this link: https://www2.htw-dresden.de/~huhle/ArtScienceRS485.pdf for a good introduction.
So you can write as many lines of code and drivers as you want but that won't help your TTL UART talk to RS485. Even if you have a device that supports RS485 on its driver, the hardware itself needs to have a level translator IC (like a MAX485) for you to be able to use it. Fortunately, our beloved Linux Kernel developers know a lot about hardware and you don't have to worry about this (for most devices anyway). Then, answering your question: if you are not able to find the RS485 settings on your driver it will most likely mean your hardware does not offer support directly.
Luckily for you, the solution is quite easy: just get a cheap USB to RS485 dongle. You can find them from 5-10$ and they should work fine out of the box for most scenarios. In my experience, FTDI chips work well.
If you really have to go with one particular UART for any reason whatsoever, for instance, imagine you want to use the UART on your Raspberry Pi or any other where you only have TX and RX signals accessible. Then you have a slightly more difficult challenge ahead of you and you need to study a bit more about how RS485 devices work. The key aspect here is to understand that RS485 on a half-duplex two-wire link (see note below for more details on this). To be able to share a two-wire bus where one or multiple devices are listening and only one is talking at any time, you need an additional control signal (Drive Enable/~Read Enable) on top of your TX and RX (note that when you go on single-ended TTL you have two signals referred to GND using three wires compared to one differential bus with two wires for the RS485 side). Your RS485 transceiver (say MAX485) will need this RE/~DE signal to arrange who is talking and who is listening on the bus, namely: all devices listening on the bus will have this signal low (read enable set) while the talker will be high (drive enable).
Here we get to the essence of your question: where can you get this additional signal? Well, the answer is: it depends on your UART chip. Some chips don't offer anything to work with, then you're left with the option of manually driving in your software application a GPIO line or flow controls signals (RTS or DTR) for UARTS where you have them available. You can read more details on this topic for the particular case of the FTDI chips here: RS485: Inappropriate ioctl for device. There is also a reference to a nice hardware solution to this problem using the mythical 555 timer IC.
Note: more confusing areas: one, RS485 is half-duplex and sometimes mixed up with RS422, which is full duplex and needs four wires; and two: where I say two-wire and four wires I should better say three-wire and five wires because the differential voltage signals need a GND to serve as a return path; sadly, most practical implementations of RS485 are two-wire and they seem to work reliably for most people, but that's a huge topic itself and we can talk about it somewhere else.