AM335x GPMC access from a Linux user space application does not open /dev/mem

Sergio Kamakura

I am developing a video capture cape board for BeagleBone Black, that uses GPMC as the interface to send image buffers to applications.

The GPMC, in principle, is properly initialized by a device tree dtbo and the internal eMMC of BBB is disabled. I am using linux version 4.1.18-ti-r52 ( debian 4.9.2-10 ). Dmesg shows that my cape board was properly initialized:

[    3.406819] bone_capemgr bone_capemgr: Baseboard: 'A335BNLT,00C0,2414BBBK1726'
[    3.406847] bone_capemgr bone_capemgr: compatible-baseboard=ti,beaglebone-black - #slots=4
[    3.441224] bone_capemgr bone_capemgr: slot #0: 'DVE-1501,00A0,WARPTEC,DVE1501'
[    3.497098] bone_capemgr bone_capemgr: slot #1: No cape found
[    3.557099] bone_capemgr bone_capemgr: slot #2: No cape found
[    3.617087] bone_capemgr bone_capemgr: slot #3: No cape found
[    3.623052] bone_capemgr bone_capemgr: initialized OK.
[    3.625926] omap-gpmc 50000000.gpmc: GPMC revision 6.0
[    3.625949] gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
[    3.626246] gpmc_read_settings_dt: page/burst-length set but not used!
[    3.627175] bone_capemgr bone_capemgr: slot #0: dtbo 'DVE1501-00A0.dtbo' loaded; overlay id #0

For testing purposes, I am using a user space application for basic tests.

But, when I try this initialization procedure to acess physical address from user space, I can't open /dev/mem:

    do
    {
        fd = open("/dev/mem", O_RDWR | O_SYNC);

    } while (fd == -1 && errno == EINTR);

    if (fd == -1)
    {
       perror("Do not open /dev/mem");
        return errno;
   }

The error message says: Do not open /dev/mem: Permission denied.

I wonder that "/dev/mem" it is not related with GPMC hardware specifically, mainly if GPMC is not properly initialized. Or not?

What I am doing wrong?

Sergio

over 9 years ago

0 Yordan Kovachev over 9 years ago

TI__Guru**** 161600 points

Hi Sergio,

The /dev/mem shouldn't be related specifically to the GPMC hardware.

I think your problem is in the do-while loop:

do {

fd = open("/dev/mem", O_RDWR | O_SYNC);

} while (fd == -1 && errno == EINTR);

the loop opens /dev/mem for read/write on the first go and probably locks the resource, then on the next try you cannot open /dev/mem and you exit the loop with the error message.

I'd recommend to remove the do-while loop and simply use:

fd = open("/dev/mem", O_RDWR | O_SYNC);

if (fd == -1) prerror("Couldn't open /dev/mem\n");

Or:
if((fd = open("/dev/mem", O_RDWR | O_SYNC)) == -1) prerror("Couldn't open /dev/mem\n");

To verify this, try using devmem2 in the console, for example to read some PRCM retister, i.e. devmem2 0x44E00030 => this should read the value of CM_PER_GPMC_CLKCTRL. If the devmem2 function executes correctly in user space, then change your api code, as I specified above.

Best Regards,
Yordan

0 Sergio Kamakura over 9 years ago in reply to Yordan Kovachev

Expert 2495 points

Hi Yordan

I needed to download and compile devmem2, as it doesn't exist in this linux version that I am using. But, as you can see, devmem2 says the same problem: Permission denied. Follows what I did:

debian@beaglebone:~$ wget www.lartmaker.nl/lartware/port/devmem2.c

--2016-05-05 09:27:50--

Resolving www.lartmaker.nl (www.lartmaker.nl)... 69.93.127.100

Connecting to www.lartmaker.nl (www.lartmaker.nl)|69.93.127.100|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 3551 (3.5K) [text/x-csrc]

Saving to: ‘devmem2.c’

devmem2.c 100%[===============>] 3.47K --.-KB/s in 0s

2016-05-05 09:27:50 (22.9 MB/s) - ‘devmem2.c’ saved [3551/3551]

debian@beaglebone:~$ gcc devmem2.c -o devmem2

debian@beaglebone:~$ sudo cp -t /usr/local/bin/ devmem2

debian@beaglebone:~$ devmem2 0x44e00030

Error at line 69, file devmem2.c (13) [Permission denied]

debian@beaglebone:~$

I changed the program as you said and the same problem: Permission denied.

Do you have a simple working example that works with virtual to physical memory access?

Sergio

0 Sergio Kamakura over 9 years ago in reply to Sergio Kamakura

Expert 2495 points

Yordan

I found that running my program as root, the Permission denied disappears.

But, this create another question: how to programmatically be root when try to open "/dev/mem"? Is it possible?

Sergio

0 Yordan Kovachev over 9 years ago in reply to Sergio Kamakura

TI__Guru**** 161600 points

Hi Sergio,

You are using debian on your bbb, not the TI SDK, right?
If so, have you tried to log in as root after you boot-up? Then you shouldn't need to execute sudo <command>.

Best Regards,
Yordan

0 Sergio Kamakura over 9 years ago in reply to Yordan Kovachev

Expert 2495 points

Hi Yordan

I am using debian Jessie in my BBB.

Yes, if I log as root or give sudo su, my test program executes normally.

As this test program, as its name says, is for testing purposes, it is sufficient for this hardware debugging step.

I am testing GPMC interface, from where I will capture the digitalized images from our video grabber cape board. As I don't have the linux driver yet, I need some "tricks" in user space, to access GPMC, physical memories, gpio, I2C ( video decoder chip ), and so on.

In this right moment, I can capture something, but I am not sure if is images, so, debugging continues. My partner modified the FPGA that controls the data flux, inserting a counter ( increments with each read ) that will intercept the data and replace it with the counter contents, so, I will grab sequential counting, that will prove that the GPMC interface is running OK. Next step is capture images and send them directly to framebuffer. If images are perfect, the hardware debugging is finished.

Anyway, thank you very much for you support.

Sergio

Processors

Processors forum

AM335x GPMC access from a Linux user space application does not open /dev/mem