I got a RFID reader (GigaTek PCR330A-00) that is meant to be recognized under linux/windows as a (Human Interface Device) keyboard/USB.
I hate to say this but it is working as a charm under Win7 but not "really" under Linux.
Under Debian-like distros (x/k/Ubuntu, Debian,..), or Gentoo, or... I just can't have the device working at all: the device scan well (it has its USB 5V, so it is happy/beeping/blinking) something happened in the dmesg, but no immediate screen display of the RFID Tag code as expected (and seen under win7)
Support is claiming it is ok under RHEL or SLED "enterprises" distros... and I must admit I saw it working under a RHEL4... I tried stealing the driver but did not succeed having my reader working...
My question is thus double:
1./ How can I hack the kernel to add support to my device (simply register PID/VID?) ?
2./ What is different at all in a "enterprise" proprietary distro? how can I re-use it?
Thank you for any hint/help.
Cheers,
If you have the source code of the driver you can compile it against the current Kernel your system uses, since the Kernel only allows drivers for its current version. Then you can try to load it as a Kernel module, notice that by doing this, you do not hack the Kernel you just need your current system's Kernel header to compile the driver against it.
You may want to check this http://www.freesoftwaremagazine.com/articles/drivers_linux in order to grasp the basics.
Hope this helps.
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'm trying to backport a Linux kernel driver (the PCF85063 RTC, specifically) from the 3.17+ kernel into a 3.14 kernel I'm using, and I'm running into a few issues. I don't have any experience with adding/modifying kernel drivers, so I'm not sure if what I've done so far is correct:
I took the rtc-pcf85063.c file from the newer kernel, and added it to my drivers/rtc/ directory in the kernel source.
I added the following line to drivers/rtc/Makefile:
obj-$(CONFIG_RTC_DRV_PCF85063) += rtc-pcf85063.o
I added this snippet to drivers/rtc/Kconfig
config CONFIG_RTC_DRV_PCF85063
tristate "NXP PCF85063"
help
If you say yes here, you get support for the NXP PCF85063 RTC.
From my understanding, that should be all it takes to add driver support for the new RTC. When I execute make menuconfig, I can see my new RTC entry under Device Drivers > Real Time Clock, labeled as NXP PCF85063 with the correct help information. So it's clear that the third step above was successful.
The problem is, when I include this driver (by selecting it in menuconfig and saving/exiting) in my kernel build, it doesn't actually get built in. If I deploy the kernel and read /lib/modules/3.14.17/modules.builtin, the new driver is nowhere to be found. Also, if I check drivers/rtc/ after building the kernel, there are object files for every RTC driver included through menuconfig except the new one; the kernel isn't even compiling the driver.
I found one interesting thing that might give some hint as to what's going on. When I go to include/config in the linux source after running menuconfig, I have a bunch of directories, some of which correspond to drivers. There's an rtc directory, and when I navigate to include/config/rtc/drv, there's a header file for every RTC driver included in the build except the one I added.
The thing is, the header file corresponding to the new driver is in include/config; it's hidden away in include/config/config/rtc/drv. It looks like menuconfig isn't treating the new driver as a regular RTC driver.
I know this is a pretty specific problem, but I was hoping that someone might notice that I'm missing a step or going about this the wrong way. Thanks.
I am trying to enable Arduino-like serial output for my BeagleBone Rev5.
From what I understand the UART mapping is like this:
UART0 <=> /dev/ttyO0
I am running the latest Angstrom distro:
http://downloads.angstrom-distribution.org/demo/beaglebone/Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.12-beaglebone-2013.04.13.img.xz
I have disabled the Angstrom default getty on /dev/ttyO0 by modifying this file:
/etc/systemd/system/getty.target.wants/serial-gett#ttyO0.service
(gleaned from this question: Automatic login on Angstrom Linux)
I commented everything out which I believe should stop getty from starting on that port. Once done I rebooted the board and am no longer able to connect via serial console so that seemed to work.
But I now cannot find any reliable information on how to configure that UART so I can transmit data. I have looked extensively but all the documentation refers to older versions of Angstrom that don't seem to reflect the most recent release.
For example they all say to exec a command like this:
root#beaglebone:~# cat /sys/kernel/debug/omap_mux/uart1_rxd
(http://www.gigamegablog.com/2012/01/22/beaglebone-coding-101-using-the-serial-and-analog-pins/)
But when I try that, there's nothing there:
root#beaglebone:/sys/kernel/debug# ls
asoc gpio musb-hdrc.0.auto regulator usb
atmel_mxt_ts hid musb-hdrc.1.auto sched_features wakeup_sources
bdi iio pinctrl suspend_stats
bluetooth kprobes pm_debug tracing
dri memblock pwm ubi
f2fs mmc0 regmap ubifs
root#beaglebone:/sys/kernel/debug#
The latest release of Angstrom seems to be from April 2013 which is much newer than most of the blog posts I've seen regarding this. It seems that the new version of Angstrom does things differently than the old versions. Does anyone have any idea how to actually USE the various hardware on the new versions of Angstrom/BeagleBone?
root#beaglebone:/sys/kernel/debug# uname -a
Linux beaglebone 3.8.6 #1 SMP Sat Apr 13 09:10:52 CEST 2013 armv7l GNU/Linux
root#beaglebone:/sys/kernel/debug#
I'd love a specific answer but would be quite satisfied with any information I can get regarding how things work in the newer versions of Angstrom.
EDIT:
Turns out I just didn't try hard enough. I plugged the BeagleBone into the network and did
opkg update
opkg install python-pyserial
Once that was done I was able to write a small program that would dump out over the built-in serial/USB port (/dev/ttyO0) at whatever data rate I want.
With getty for serial disabled I can write as much as I'd like without issue. If the getty is turned back on it'll interrupt my connection whenever it detects something is happening at a slower speed, at that slower speed.
Thanks for all the help. I especially appreciate the information about how nothing is figured out re:device tree since that's a problem I'm going to face myself as I try and use a BeagleBone for other projects.
The command you showed has nothing to do with baud rate, it controls pin muxing. Many microcontrollers have many more peripheral functions than I/O pins, so the I/O pins need to be mapped to peripherals, and not all connections are possible. For your case, you need to designate particular pins as UART transmit and receive.
I haven't done it myself, but I found a considerable amount of documentation describing that control of pin muxing via sysctl and the proc filesystem was recently replaced with a new system based on Device-Tree. And that as a result virtually all existing examples are broken. Worse, there may not even be a working device-tree-based equivalent for some commands.
As far as setting the baudrate, you would normally use cfsetispeed() and cfsetospeed() from termios.h, as described in the Unix specification.
You don't specify the language you want to use.
In any case, I think you'd better study the Serial Programming Guide for POSIX Operating Systems, which will give you al lot of informations about how serial ports are handled in Linux
I work with raling rt73 usb device on Ubuntu 8.04 (kernel version 2.6.24) on lpia (Intel Atom) platform. The device is handled by rt2x00 drivers that are part of the kernel. The scan routines are performed incorrect (eg. wrong signal quality and redundant networks are detected). I want to fix these issues, but I cannot find the place in the driver code where those mentioned values are calculated. Unfortunately neither the driver is exhaustively documented, nor the website of the project provided me with useful information.
I wanted to track how the ioctl commands are executed (e.g. SIOCSIWSCAN or SIOCGIWSCAN commands) but they are not mentioned in the code (grep SIOCSIWSCAN * returns nothing). Also the struct, where the scan results are stored (struct iwreq) does not exist in the code.
I am fresh to drivers so maybe I am approaching the problem in wrong way. Can you push me in right direction?
I have a problem probably with my arm toolchain but maybe there's something other that I do wrong. I have Chinese made dev board qq2440 using Samsung s3c2440 ARM9 uC. I'm using Ubuntu x86 with native gcc(4.3.3) and cross-compile version arm-unknown-linux-uclibc-gcc (crosstool-NG-1.3.2) 4.3.2
I followed tutorials from http://blog.leshak.ru/english/pages/how-to-install-u-boot-linux-2629-rootfsjffs2-busybox-1132-into-nand-qq2440/
and used Leshak's kernel patches for that board. Problem is that his binaries work perfectly and mine don't...
I communicate with my board over RS232 (serial port) and I have serial terminal configured on target Linux. I use Leshak's uboot image. To configure my kernel I use following command line:
qq2440> setenv bootargs 'noinitrd root=/dev/mtdblock2 rootfstype=jffs2 rw console=ttySAC0,115200'
For target I use vanilla Linux sources version 2.6.29, with patches created by Leshak. I don't honestly believe that this will ever be supported officially by Linux as it's not mainstream product.
My kernel image starts booting up, but it probably changes bandwidth (or CPU frequency) to some non standard value (tried all standard ones already). Instead of dots indicating loading kernel into memory I've got only trash instead. Unfortunately it doesn't probably finish the boot process as the network interface nor file system don't come up. So I figured out that it panics somewhere in the middle.
Any ideas what should I do next?
Thanks & regards,
Chris
There are a lot of different things that could be going on here.
It sounds like you are talking about a serial port, and that it appears to be giving garbage once control is passed to the kernel from uboot. Am I understanding that correctly?
Look into specifying the baud rate, parity, etc. for the serial console on the kernel commandline.
Oh, and IIRC, there was some 'early_printk' thing in the ARM Linux tree that might help you debug serial console problems. (But I'll warn you -- it's been a couple years since I dealt with that so my memory is fuzzy.)
Double-check that the memory address layout (the locations of all the various devices) matches what your board has. (I think this is probably not the issue, but wanted to mention it for completeness.)
You say that you have a binary kernel that works correctly; compare the kernel config of that kernel to the config you are using for building your kernel. Investigate every difference, particularly any specific to ARM.
You may want to double-check the endianness of your toolchain vs what your board is expecting. Some of the ARM / XScale processors can be configured to big-endian or little-endian in software, so it might be worth double-checking.
Just enable the debug build of the kernel[while building the uImage] so that you get a more clearer picture of the scenario [Just would make your boot up somewhat slow since all the printk's would be enabled].
Can you check whether you are passing the correct parameters to the UART ie. Serial Port Name, it's baud rate etc This would be provided by the board manufacturer-Samsung
WRT the network instead of DHCP can you just assign a static ip address to your system as it might be possible that the DHCP process is still not ON.
Also a better option would be to use NFS but yeah, it depends on your choice and the purpose of your application. To use NFS, your network should be UP & running and your filesystem should be shared.
As retracile has already pointed out "Endianness" could be a point to look into !!!
You can refer this link which might help you out since it is specific to S3C2440
Hope this helps.
-hjsblogger
I had a similar problem at one point when I omitted --send-cmd from picocom. this is the command I issue to picocom for serial uBoot comms with the mini2440.
picocom -b 115200 /dev/ttyS0 --send-cmd "sx -vv"