Actions
Forum Thread Details
  • State Verified Answer
  • Replies 10 replies
  • Subscribers 329 subscribers
  • Views 3366 views
  • Users 0 members are here
Related

Linux /dev/mem accessing switch values

Former Member

After reading a lot of posts it seems like I am on the right track for doing this correctly, but yet it still does not quite work.

Kernel: http://www.wiki.xilinx.com/Zynq+2015.4+Release

I took the zedboard release file, extracted it, and then copied it over to an SD card and booted from that. Seems to work fine.

Tools: Vivado 2015.4 and SDK 2015.4

After that, I create a hardware .bit file using an AXI GPIO IP block to connect to the PS to the switches. I generate the .bit file, export it to the SDK, and then launch the SDK.

Based on the system.hdf file, the axi_gpio_0 is located at 0x41200000. So this is where I assume I need to mmap /dev/mem in order to access the values.

I start a new application project, select Linux, and create the C++ project. Then I program the FPGA after the OS has been loaded from the SD card.

The code I use to try and access the values at the AXI_GPIO address is below. I try to map just one byte because the GPIO register with the values is in the first byte (at least I believe it is...). I have also tried mapping 0xFFFF bytes (which is the end address of the AXI GPIO block) and getpagesize() bytes as well (so 4096 in this case).

Even more aggravating is when I do a bare metal application and de-reference 0x41200000, it accurately reads the switches.

I also tried it as a Linux C application, but that too hangs so it is not C++ versus C related as far as I can tell.

I am using the SDK's TCF to download and run the application. It runs in /tmp/ (not sure if that is important or not...)

#include <iostream>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/fcntl.h>

const unsigned int64_t gpioAddr =  0x41200000;

int devMemSwitchTest()
{

tint x = 0;
tint fd = 0; fd = open("/dev/mem", O_RDWR | O_SYNC);
tvolatile unsigned int* addr = NULL;
tvolatile unsigned int* start = NULL;
toff_t offset = gpioAddr & ~(getpagesize()-1);


tif (fd == -1)
t{
ttperror("Failed to open /dev/mem: ");
ttclose(fd);
ttreturn -1;
t}

tstart = (unsigned int*)mmap(NULL, 1, PROT_READ | PROT_WRITE, MAP_SHARED,
tttfd, offset);
tif (start == MAP_FAILED)
t{
ttperror("ERROR with mmap: ");
ttmunmap((void*)(start), getpagesize());
ttclose(fd);
ttreturn -1;
t}
taddr = (unsigned int*)start + (gpioAddr - offset); //this happens to evaluate to addr = start since it is already page aligned.
t
t//unsigned int y = *((unsigned int*)start); <-- freezes here if not commented out!!

tmunmap((void*)(start), getpagesize());
tclose(fd);
treturn 1;
}

int main() {

tstd::cout << "Attempting to opend /dev/mem" << std::endl;
tdevMemSwitchTest();

tstd::cout << "We made it!!!" << std::endl;
treturn 1;
}

Thanks in advance for any help provided! This has been driving me crazy for the past two days now...

Mark

Parents
  • 0

    Hi Mark,

    When the device hangs on a memory-mapped write, it is a possible symptom of unconfigured programmable logic and the fact that AMBA buses are "dumb" (i.e., have no notion of device enumeration). By this, I mean that the OS will always just take the device tree's word for it as to whether a given physical address is actually mapped to any physical memory/device (or in the case of an mmaped /dev/mem write, it will take the user's word for it). Thus, if a memory-mapped peripheral is not actually present in the PL, the host processor will begin an AXI transaction that will never finish (since the bus is disconnected) and the system will hang. This is one of the dangers of using the otherwise excellent bring-up technique of userspace pseudo-drivers.

    If you go back to the original system, mount your SD card into the VFS to access the *.bit file. After you pipe the *.bit file into /dev/xdevcfg check to see if the problem is still there. My suspicion is that after this manual configuration step in the original system, you might find the peripheral works as intended. If this is the case, it suggests that the issue was that the PL was not being configured at boot. If this is the case, check the order of the entries in your original boot.bif, and make sure that it goes:

    the_ROM_image:
    {
        [bootloader]fsbl.elf
        pl.bit
        u-boot.elf
    }

    If it does not appear in this order, it is possible that the bootloader will pass control to U-Boot or whatever boot system you are using before the PL gets configured, which would then be the root cause of the original failed /dev/mem writes.

    Just had an issue with ordering the boot.bif ordering earlier today! Couldn't figure out why the device wasn't getting configured at boot.

    -Tom

  • 0 in reply to Former Member

    Hey Tom,

    That was more or less the issue. I needed to rebuild the boot.bin as well as edit the device tree from the original 2015.2 Xilinx release. Once I did those steps it worked like a charm!

    Thanks for the explanation of the OS hanging; I was wondering why that kept happening.

    Mark

Reply Children