Re: [beagleboard] Memory Mapped GPIO, has the addressing changed?

2,664 views
Skip to first unread message

Gerald Coley

unread,
May 4, 2013, 8:52:42 PM5/4/13
to beagl...@googlegroups.com
Te new processor is the old processor. BBB uses the same processor as the BeagleBone. It is just a higher speed version. They are the same.

Gerald



On Sat, May 4, 2013 at 6:17 PM, <ky...@cranehome.info> wrote:
If been able to find a couple of libraries that deal with GPIO on the BeagleBone.  I have tried to compile and execute them on the BeagleBone Black but have had no success thus far. One library is a C library and tries to set the MUX via the now missing omap_mux file and fails at that point.  It's mimicking the Arduino style DigitalWrite syntax.  The other one is a C++ library that appears to try to access the MUX settings through memory as well. 

Both Libraries seem to have a base address for the GPIO pins as:
#define GPIO0   (0x44E07000)
#define GPIO1   (0x4804C000)
#define GPIO2   (0x481AC000)
#define GPIO3   (0x481AE000)
 

The control register base seems to be set as this:
const unsigned long Beagle_GPIO::GPIO_Control_Module_Registers = 0x44E10000;


This is the C++ library I found.

and was able to compile it but had to add: 
#include <unistd.h>
to the Beagle_GPIO.hh to cover the use of usleep in several places before it succeeds in building.  Running the test executable however results in:

root@beaglebone:~/downloads/Beagle_GPIO-master# ./Beagle_GPIO_test
[GPIO] : Beagle_GPIO::Beagle_GPIO()
[GPIO] : Opening /dev/mem
[GPIO] : Beagle GPIO Initialized
[GPIO] : ====================
[GPIO] : BeagleBone GPIO Test
[GPIO] : ====================
[GPIO] : Configuring Pin P8_46 as Output
Bus error

So the error suggests that something about the addressing is not right.  Has the BBB new processor changed the memory map locations around?

I'm just searching for a way that allows me to use the GPIO pins in a straight-forward way.  I have several C/C++ programs I have been using on the RaspberryPi and wanted to port over to the BeagleBone Black but they need to have access to the GPIO pins.  At present I have no option it seems to move forward with this since file operations on exported pins is not going to cut it for my needs.  

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
Gerald
 

MH

unread,
May 5, 2013, 6:43:12 PM5/5/13
to beagl...@googlegroups.com

I am having similar issues with the memory mapping.  Be sure to post, if you find a solution.  Still searching...

Jacek Radzikowski

unread,
May 5, 2013, 7:13:10 PM5/5/13
to beagl...@googlegroups.com
In Linux world you are not forced to upgrade to the newest release of
OS just to ensure uninterrupted flow of cash. Install 3.2 kernel,
which is still actively maintained and updated and use you "old dog's"
tricks. If you want to stay on the bleeding edge expect to have to
learn something new every now and then.

j.


On Sun, May 5, 2013 at 7:02 PM, <ky...@cranehome.info> wrote:
> I will update if I come across anything but after a long weekend I think I'm
> going to put it away for a while. The 3.8 kernel has clearly made a mess of
> things and I think it's going to take time before all the issues are ironed
> out and some reasonable instructions that weekend hobbiest mortals can
> follow are out there. Disappointing but I guess not unexpected.
>
> Funny that MS gets ripped up and down when they break everything to
> implement the next big thing but in the Linux world your supposed to just
> smile and dig into the source to figure out what they did.
>
>
>
> On Sunday, May 5, 2013 5:43:12 PM UTC-5, MH wrote:
>>
>>
>> I am having similar issues with the memory mapping. Be sure to post, if
>> you find a solution. Still searching...
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
Given a choice between two theories, take the one which is funnier

ky...@cranehome.info

unread,
May 5, 2013, 7:25:31 PM5/5/13
to beagl...@googlegroups.com
Yes, as I said..... "Disappointing but I guess not unexpected."

At this point I don't see much to learn beyond lots of things don't work yet, so I'll let the bigger brains sort some of it out before I go forward.  I don't have the familiarity or expertise to help to much in that arena. I'll have to crack some books on Device Tree I guess because my pouting aside, It's going to have to be dealt with.

Jacek Radzikowski

unread,
May 5, 2013, 7:37:34 PM5/5/13
to beagl...@googlegroups.com
Device tree mechanism is quite interesting and it's good to learn to
use it early, so you will have a transition to the new line of
kernels. You can get a stack of books (once they will be printed), but
for me good starting points were
https://github.com/jadonk/validation-scripts/tree/master/test-capemgr
and source files for cape firmwares from the new kernel. After you get
the feeling how DT works, you can read about details on
http://www.devicetree.org/Device_Tree_Usage
Unfortunately thorough documentation of all new features lags behind
the development and in such cases the best documentation is usually
the source code.

j.

ky...@cranehome.info

unread,
May 5, 2013, 11:15:47 PM5/5/13
to beagl...@googlegroups.com
Thanks for the links!  That first one is very helpful to get started.

stuie_...@yahoo.com.au

unread,
Jul 17, 2013, 5:53:32 AM7/17/13
to beagl...@googlegroups.com
All

Has anyone found a solution to this? 

I am mapping /dev/mem and setting the GPIO input / output in a similar fashion to the referenced example by the OP.

From dmesg I see
[267773.389824] Unhandled fault: external abort on non-linefetch (0x1018) at 0xb6f71134

In a TI forum I came across http://e2e.ti.com/support/embedded/linux/f/354/t/49197.aspx

"You need to make sure that the appropriate McSPI functional (CM_FCLKEN1_CORE)  and interface (CM_ICLKEN1_CORE) clocks are enabled before reading the McSPI registers."

Is this solution - especially since I am not using SPI?  What exactly does it mean?

Thanks

Stuart

Charles Steinkuehler

unread,
Jul 17, 2013, 8:22:26 AM7/17/13
to beagl...@googlegroups.com, stuie_...@yahoo.com.au
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/17/2013 4:53 AM, stuie_...@yahoo.com.au wrote:
> All
>
> Has anyone found a solution to this?
>
> I am mapping /dev/mem and setting the GPIO input / output in a
> similar fashion to the referenced example by the OP.
>
> From dmesg I see [267773.389824] Unhandled fault: external abort on
> non-linefetch (0x1018) at 0xb6f71134
>
> In a TI forum I came across
> http://e2e.ti.com/support/embedded/linux/f/354/t/49197.aspx
>
> "You need to make sure that the appropriate McSPI functional (*
> CM_FCLKEN1_CORE) * and interface (*CM_ICLKEN1_CORE) *clocks are
> enabled before reading the McSPI registers."
>
> Is this solution - especially since I am not using SPI? What
> exactly does it mean?

You need to activate the low-level GPIO hardware (ie: take it out of
reset and provide a clock). The easiest way to do this is to export a
GPIO pin using the sysfs interface. You can then talk to anything
else in that group of pins via direct register access.

Note that there are two hardware groups. GPIO bank 0 is on it's own,
and banks 1, 2, and 3 are grouped together.

- --
Charles Steinkuehler
cha...@steinkuehler.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHmjIIACgkQLywbqEHdNFyCEgCg9ltzNB+RFpKo9rhIKTQTgpv2
2/kAnRAv71oXJAgZlGNisGR3LgSkXzt2
=4G8G
-----END PGP SIGNATURE-----

Jacek Radzikowski

unread,
Jul 17, 2013, 12:19:19 PM7/17/13
to beagl...@googlegroups.com
Unfortunately enabling setting pinmuxing for GPIOs does not turn on
the GPIO modules. The easiest way to enable them is to export one pin
from each of the problematic GPIO blocks. You can use the following
script: https://github.com/piranha32/IOoo/blob/master/examples/bbb_enable_gpio.sh

j.

Bo Gao

unread,
Jan 6, 2014, 11:53:13 AM1/6/14
to beagl...@googlegroups.com
Thank you,

I tried and it worked. 

Then, I  ran the Beagle_GPIO_test compiled from https://github.com/majestik666/Beagle_GPIO/blob/master/Beagle_GPIO.cc
I could see the Pin P8-46 is changed from 3.3v to 0v.
Hope this will help others who are using or trying to use the mmap to configure the pin using C/C++.

Thank you,

Bo

Saleem Ahmad

unread,
Feb 7, 2014, 2:05:46 PM2/7/14
to beagl...@googlegroups.com
Try using
#define GPIO *((volatile unsigned long *)0x44e...)
Reply all
Reply to author
Forward
0 new messages