So, I recently got an APU3 board (like this one: Board Link). I decide to load PFSense on this, which runs on FreeBSD. There are GPIO ports on the board, which can be seen through the documentation as well. I found this command called gpioctl, which does not work in triggering the GPIO pins as it needs this directory called dev/gpio which is not present in the dev directory. GPIO pins are not present in the sys directory as well(in fact, I have no sys directory). Is there any way I can control my GPIO pins?
Thank you
Related
I created a simple module that controls wheter a USB supplies power for a device when in host mode or not. When loaded, this module cuts off the power to any device connected until told otherwise.
It is also desired that when booted, the system comes with both my module loaded, and the USB supply cut off. To this end, so far I've tried:
Setting my module as a kernel built-in: had no effect, modules that are loaded later overrun my configuration;
Creating an init.d script: Created the script, and set it up to run on rc5. No luck as well, I run into multiple problems with USB devices (such as usb 2-1: device descriptor read/64, error -110);
I'm running Kernel 3.12 on a custom board, and I've tested that the module works as intended if I load it manually (via modprobe) into the system, after logging in.
Ideally, I want to keep these configurations to be done during boot, without any need of logins and such.
So, my question is: how can I postpone the module loading until the last possible minute, assuring that any other configuration is already finished? Also, is udev a good solution for this sort of thing? From what I read, I had the impression it wouldn't be the best fit...
Regards,
Guilherme
So, I've figured out how to get rid of the errors when using an init.d script. All that is needed is to unbind the devices before loading the module. the following line before the modprobe did the trick for me:
echo "2-1" > /sys/bus/usb/drivers/usb/unbind
Regards,
Guilherme
I am building a robot and want to use gForth to develop the software. I am unable to tell, after looking through the manual and searching on the web, whether or not the GPIO pins can be changed from within gForth running on a Raspberry PI 2. In Python there is the GPIO library that gets imported. But, I see no provision for that in gForth.
Has anyone had success in doing this from gForth? Your help is greatly appreciated.
This might be a little late, but here's what I do. I access the port using the /sys/class/gpio/ file structure. It means using the EXPORT file, the DIRECTION file and the VALUE file. It works perfectly.
Let me know if you need more info.
I'd like to find a way to make my BeagleBone (white) Rev A6a autologin after being powered up. I'm using Angstrom with kernel 3.2.34, which uses systemd instead of innitab.
I've already seen some topics (like this question) with reference to modifications on some service files (like /etc/systemd/system/getty.target.wants/getty#tty1.service), but that only helped me partly: If I power/reset my BBone while keeping it connected via USB to my computer, it autologs as expected. But, if I just power the BBone with a wallwart (without any other connections), it doesn't seem to log in. At least I believe that's what is happening, as I have a program prepared to autorun after login and it only starts on the first case (with USB on).
I'd appreciate any help. Thanks.
Turned out that a RF module attached to my beaglebone was being powered via USB, and this module should be activated by my test program mentioned in the question. So, when I unplugged my BBone USB cable, I was actually separating its GND from the RF Module's ground.
In short, I just had to use the same source in the entire circuit and keep the autologin configuration explained in the topic I also mentioned in my question.
You could make your program a service and run after user instance of systemd.
Lets say you have a graphical.target in your /usr/lib/systemd/system then just put symlink to ../systemd-user#.target to /usr/lib/systemd/system/graphical.target.wants/system named like systemd-user#<your-user-name>.service.
This systemd-user#.service should containe ExecStart line like /usr/bin/systemd --user.
Then you'll have to add your application's service-file to /usr/lib/systemd/user.
More info is at http://www.freedesktop.org/software/systemd/man/systemd.html and http://www.freedesktop.org/software/systemd/man/systemd.unit.html
Yesterday I faced with an interview. In interview he asked me for steps to porting Linux on new board.
My answer was,
cross-compile u-boot for board architecture.
cross-compile kernel, with selecting driver for peripherals connected to board.
cross-compile filesystem, and port all on board.
But Interviewer is not happy with this answer.
Can you please suggest me which point were I missed out?
Thanks in advance.
Porting steps -
Install a cross-development environment.
Setup the board and ensure that the serial port is working so we can print data through the serial port.
Download and install the Linux kernel, most of the porting work will be done at this level.
Add board specific code into the kernel tree.
Build a kernel image to run on the board
Test that early kernel printk is working
Get the real printk working with the serial console.
For a new board, a new board-specific directory should be added as well as support for interrupt handling, kernel timer services and mapping for memory areas.
Ethernet drivers are usually the next drivers to focus on as they enable setup of NFS root file system to get access to user utilities and applications.
Filesystem can be provided in different forms which are listed on LinuxFilesystem
On this machine: http://www.nexcom.com/ProductModel.aspx?id=376f4fa5-64f3-41d1-afba-60ee48883465
I'm trying to access gpio, but neither Nexcom or Intel support has been very helpful.
The closest I've come is this blog post which says I have to write my own driver: http://geekswithblogs.net/BruceEitman/archive/2010/08/01/windows-ce-using-a-driver-to-readwrite-hardware-registers.aspx
From the nexcom manual it states gpio port is located at 0EE4H (0xEE4). What am I supposed to with this info? Am I really supposed to write my own driver?
edit: is must work on windows xp embedded and windows 7 embedded.
You can't directly access hardware resources (like GPIO pins) from userspace processes unless there's a driver that exposes this functionality. This means that either you find a suitable driver (I have no clue about where to look for such a thing) or you write your own.
p.s. It may also be the case that your OS expose the GPIO pins somewhere. On a linux prototyping board I worked on once there were a few files (IIRC /dev/gpioX, with X being the number of the pin) you could read/write to if you had the appropriate permissions.
You need GIVEIO.SYS.
It actually comes from Microsoft originally.
when you install it, you specify what port addresses you want.
then the user space program can access the ports directly.
You unix bretheren can just call ioperm() instead with the process running as a root. A shame MS didn't do that, but GIVEIO.SYS is okay.