element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • About Us
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Avnet Boards Forums
  • Products
  • Dev Tools
  • Avnet Boards Community
  • Avnet Boards Forums
  • More
  • Cancel
Avnet Boards Forums
Software Application Development Linux /dev/mem accessing switch values
  • Forum
  • Documents
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Avnet Boards Forums to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • State Verified Answer
  • Replies 10 replies
  • Subscribers 329 subscribers
  • Views 3254 views
  • Users 0 members are here
Related

Linux /dev/mem accessing switch values

Former Member
Former Member over 9 years ago

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

  • Sign in to reply
  • Cancel
Parents
  • zedhed
    0 zedhed over 9 years ago

    Hi Mark,

    I had a question about why the unsigned int64_t gpioAddr is needed to be declared as that wide of an integer when we are dealing with a 32-bit memory space on this platform?

    I have not tried this out yet, but we use the AXI GPIO blocks in our factory test to do a simple I/O loopback on the FMC connector.  This is currently being done under 2015.2 PetaLinux but will be tested under 2015.4 eventually.

    For this, two main pieces are needed: the DTS entry for your AXI GPIO block and some sort of mmap function into that PL memory space for the AXI GPIO block:

    My DTS entry looks like this for the two AXI GPIO blocks used in the test:

    axi_gpio_0: gpio@41200000 {
    ttt#gpio-cells = <2>;
    tttcompatible = "xlnx,xps-gpio-1.00.a";
    tttgpio-controller ;
    tttreg = <0x41200000 0x10000>;
    tttxlnx,all-inputs = <0x0>;
    tttxlnx,all-inputs-2 = <0x0>;
    tttxlnx,all-outputs = <0x0>;
    tttxlnx,all-outputs-2 = <0x0>;
    tttxlnx,dout-default = <0x00000000>;
    tttxlnx,dout-default-2 = <0x00000000>;
    tttxlnx,gpio-width = <0x12>;
    tttxlnx,gpio2-width = <0x12>;
    tttxlnx,interrupt-present = <0x0>;
    tttxlnx,is-dual = <0x1>;
    tttxlnx,tri-default = <0xFFFFFFFF>;
    tttxlnx,tri-default-2 = <0xFFFFFFFF>;
    tt};
    ttaxi_gpio_1: gpio@41210000 {
    ttt#gpio-cells = <2>;
    tttcompatible = "xlnx,xps-gpio-1.00.a";
    tttgpio-controller ;
    tttreg = <0x41210000 0x10000>;
    tttxlnx,all-inputs = <0x0>;
    tttxlnx,all-inputs-2 = <0x0>;
    tttxlnx,all-outputs = <0x0>;
    tttxlnx,all-outputs-2 = <0x0>;
    tttxlnx,dout-default = <0x00000000>;
    tttxlnx,dout-default-2 = <0x00000000>;
    tttxlnx,gpio-width = <0x12>;
    tttxlnx,gpio2-width = <0x12>;
    tttxlnx,interrupt-present = <0x0>;
    tttxlnx,is-dual = <0x1>;
    tttxlnx,tri-default = <0xFFFFFFFF>;
    tttxlnx,tri-default-2 = <0xFFFFFFFF>;
    tt};

    The test code which uses mmap() in pl_gpio_udriver.c is now up on our Github software repository.

    https://github.com/Avnet/software/blob/master/petalinux/apps/linux_fmc_loopback_test/src/pl_gpio_udriver.c

    This may have broken in 2015.4 PetaLinux but at least it gives you something that is known to have worked in something as recent as 2015.2 PetaLinux.

    Regards,

    -Kevin

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
Reply
  • zedhed
    0 zedhed over 9 years ago

    Hi Mark,

    I had a question about why the unsigned int64_t gpioAddr is needed to be declared as that wide of an integer when we are dealing with a 32-bit memory space on this platform?

    I have not tried this out yet, but we use the AXI GPIO blocks in our factory test to do a simple I/O loopback on the FMC connector.  This is currently being done under 2015.2 PetaLinux but will be tested under 2015.4 eventually.

    For this, two main pieces are needed: the DTS entry for your AXI GPIO block and some sort of mmap function into that PL memory space for the AXI GPIO block:

    My DTS entry looks like this for the two AXI GPIO blocks used in the test:

    axi_gpio_0: gpio@41200000 {
    ttt#gpio-cells = <2>;
    tttcompatible = "xlnx,xps-gpio-1.00.a";
    tttgpio-controller ;
    tttreg = <0x41200000 0x10000>;
    tttxlnx,all-inputs = <0x0>;
    tttxlnx,all-inputs-2 = <0x0>;
    tttxlnx,all-outputs = <0x0>;
    tttxlnx,all-outputs-2 = <0x0>;
    tttxlnx,dout-default = <0x00000000>;
    tttxlnx,dout-default-2 = <0x00000000>;
    tttxlnx,gpio-width = <0x12>;
    tttxlnx,gpio2-width = <0x12>;
    tttxlnx,interrupt-present = <0x0>;
    tttxlnx,is-dual = <0x1>;
    tttxlnx,tri-default = <0xFFFFFFFF>;
    tttxlnx,tri-default-2 = <0xFFFFFFFF>;
    tt};
    ttaxi_gpio_1: gpio@41210000 {
    ttt#gpio-cells = <2>;
    tttcompatible = "xlnx,xps-gpio-1.00.a";
    tttgpio-controller ;
    tttreg = <0x41210000 0x10000>;
    tttxlnx,all-inputs = <0x0>;
    tttxlnx,all-inputs-2 = <0x0>;
    tttxlnx,all-outputs = <0x0>;
    tttxlnx,all-outputs-2 = <0x0>;
    tttxlnx,dout-default = <0x00000000>;
    tttxlnx,dout-default-2 = <0x00000000>;
    tttxlnx,gpio-width = <0x12>;
    tttxlnx,gpio2-width = <0x12>;
    tttxlnx,interrupt-present = <0x0>;
    tttxlnx,is-dual = <0x1>;
    tttxlnx,tri-default = <0xFFFFFFFF>;
    tttxlnx,tri-default-2 = <0xFFFFFFFF>;
    tt};

    The test code which uses mmap() in pl_gpio_udriver.c is now up on our Github software repository.

    https://github.com/Avnet/software/blob/master/petalinux/apps/linux_fmc_loopback_test/src/pl_gpio_udriver.c

    This may have broken in 2015.4 PetaLinux but at least it gives you something that is known to have worked in something as recent as 2015.2 PetaLinux.

    Regards,

    -Kevin

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
Children
  • Former Member
    0 Former Member over 9 years ago in reply to zedhed

    Hey Kevin!

    Good catch on the int64_t. I'll knock that down to something that makes more sense.

    Thanks for the response! When you talk about the DTS entry, how would I go about making that change? Since everything I used was precompiled I am not sure how to go about changing the DTS. I know what it is and understand what it does, but I do not know how to update it appropriately.

    Maybe I will give my code a shot with the 2015.2 version and see if it behaves a little better.

    Thanks,

    Mark

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube