I have this AT91 SAM9G25 running a Embedded Linux with Busybox as distro. I already checked the datasheet but unfortunately I didn't get far, here's the problem:
There's a Pin SHDN for the shutdown. It is high during boot and I'd like to set it to low when hitting "poweroff" in Busybox - so the system is still powered on at this moment, it's just part of the poweroff-process.
I know I'll have to write a shutdown script in /etc/init.d/ . The problem is, I don't know which is the variable for the SHDN-Pin in Linux for the SAM9G25. Does anyone have an advise ? The only useful thing I got from the datasheet is, that the pin is called "SHDN" Ball=D8, but I can't work with these in Linux.
Thanks for your help
Kind Regards
You can simply use poweroff as there is a driver for the shutdown controller in the linux kernel. That driver is already using:
at91_shdwc_write(AT91_SHDW_CR, AT91_SHDW_KEY | AT91_SHDW_SHDW);
so the SHDN pin should be driven high.
You should try to check your .config file for this configurations
CONFIG_POWER_RESET=y
CONFIG_POWER_RESET_AT91_POWEROFF=y
CONFIG_POWER_RESET_AT91_RESET=y
or these:
CONFIG_OLD_CLK_AT91=y
CONFIG_AT91_SAM9_ALT_RESET=y
CONFIG_AT91_SAM9G45_RESET=y
CONFIG_AT91_SAM9_TIME=y
CONFIG_HAVE_AT91_SMD=y
CONFIG_SOC_AT91SAM9=y
depending on your kernel version
Related
I need to count the transitions of a 50KHz binary signal using a BBB. I think using the TIMER4 triggered by the external signal connected to the pin P8.07 would be the easiest way.
So, I issued the following commands to load the proper cape and setup the pin as a timer :
./config-pin overlay cape-universaln
./config-pin P8.07 timer
Everything seems to work and nothing appears in dmesg.
My question is : How can I read the value of TIMER4 ? I looked in SysFs and find nothing interesting. Nothing in /dev as well. How can I retrieve the value of the timer counter I just setup ? I'm open to a C/C++ solution as well, but I would like to avoid doing kernel-space programming.
I'm using the latest Ubuntu Linux for BeagleBone, kernel 4.1.10-ti-r21.
With a little googling I see a pps driver for the AM335x DMTimer subsystem here: https://github.com/ddrown/pps-gmtimer
It looks like it hasn't been merged upstream and the README gives instructions on building it into the 3.8 kernel - you could revert back to 3.8, or you could adapt that for 4.1, in which case you may need to tweak the Device Tree overlay as well for the newer version of the dtc compiler that's in 4.1.
You could also write a pulse counter firmware for the PRU (with only a 50KHz input it wouldn't need to be very optimized at all to catch every pulse). You could send a signal to the ARM every so often and catch that in your userspace program.
Another option would be to directly access the DMTimer registers from userspace using mmap to map the /dev/mem file (example of this method for GPIO here), but that's a pretty "hacky" way to do it, and it's generally frowned upon in the GNU/Linux world to do that sort of stuff from userspace instead of from kernal space.
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'm working an a system with embedded Linux (Kernel 2.6.31).
It is a AT91SAM9G20 chip inside, and some of the Pins are forwarded to the outside.
Now I want to use them as GPIO Inputs.
I read the gpio.txt documentation about using the GPIOs via filesystem, and that works very well 'til here. I connected some switches to the gpio-pins and I can see the result in /sys/class/gpio/gpioX/value. But now I'd like to react on a change without busy-waiting in a loop. (i.e echo "Switch1 was pressed").
I guess I need interrupts here, but I couldn't find out how to use them without writing my own kernel driver. I'm relatively new to Linux and C (I normally program in Java), so I'd like to handle the Interrupts via sysfs too. But my problem is, that there is no "edge"-file in my GPIO directory (I guess because this is only since Kernel version 2.6.33+). Is that right? Instead of "edge" I've got a uevent file in there, which is not described in gpio.txt.
In the gpio.txt documentation there was a Standard Kernel Driver mentioned: "gpio_keys". Is it possible to use this for my problem?
I guess it would be better to work with this driver than allowing a userspace program to manipulate kernel tasks.
I found a lot of codesnippets for writing my own driver, but I wasn't even able to find out which of the 600 gpio.h files to include, and how to refer to the library (cross compiler couldn't find the gpio.h file).
Sorry for newbie questions, I hope you could give me some advices.
Thanks in advance
See this for an example on how to do that. Basically, the thing you're missing is the usage of the select or poll system calls.
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.
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"