• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 101 subscribers
  • Views 1196 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Help with GPIO via SYSFS on AM3517 EVM

Chris Hartley
Prodigy 50 points
Other Parts Discussed in Thread: AM3517

I'm trying to do some simple GPIO in linux.  If I have read things correctly (including schematics) I should be able to do the following to change the USERLED3 on the EVM:

-------------------

root@am3517-evm:~# cd /sys/class/gpio/
root@am3517-evm:/sys/class/gpio# echo 11 > export
root@am3517-evm:/sys/class/gpio# cd gpio11
root@am3517-evm:/sys/class/gpio/gpio11# echo out > direction
root@am3517-evm:/sys/class/gpio/gpio11# echo 0 > value
root@am3517-evm:/sys/class/gpio/gpio11# echo 1 > value
root@am3517-evm:/sys/class/gpio/gpio11# echo 0 > value

------------------

However, that doesn't work and if I try just reading the value of the pin it gives 0, but should be a 1.  I've also tried GPIO31 and GPIO 135.

I tried this both booting the SD card that came with the kit and with a kernel that I built.

Am I missing something?

  • 0
    Guru 26430 points

    That sequence has worked for me on a Linux/Atmel platform. The fact that you get sysfs gpio directory means the kernel is configured for it. Has the LED lit up before? Perhaps the function of the pin has not been set up to be a GPIO yet. Something to do the mux. Probably have to configure it in u-boot source or Linux board specifc source.

  • 0 in reply to Norman Wong
    Expert 1205 points

    Hi Chris,

             The procedure you have followed should be working, if not  it is something to do with the mux settings. You can cross check the mux settings in the kernel by mounting debug as mention below:

    root@am3517-evm: mount -t debugfs debug /sys/kernel/debug

    root@am3517-evm:cd /sys/kernel/debug/omap_mux

     

    Hope this helps.

    Regards,

    N.S.SriHarsha

  • 0 in reply to SriHarsha N.S
    Prodigy 50 points

    Fixed by changing mux setting in /ti-sdk-am3517-evm-4.0.1.0/psp/u-boot-2009.11-psp03.00.01.06.sdk/board/ti/am3517evm/am3517evm.h

    Sorry, I'm a noob and didn't realize you had to set the mux separately.  Is this documented somewhere?  I am finding the documentation on the hardware interfaces in the PSP to be pretty scattered and not noob friendly.

    Also, is there documentation on the debug interface you referenced?  Can the mux setting be changed at runtime or does it have to remain static?

     

    Thanks,

    Chris

  • 0 in reply to Chris Hartley
    Guru 26430 points

    From what I've seen, Linux is not supposed to configure the HW. The bootloader is supposed to setup the processor for that specific board, The TI kernels seems to have moved HW initialization back and forth between U-Boot and Linux. A bit frustratiing as it might mean having to update U-Boot to match a new Linux kernel. The kernel hat I use even has a kernel flag for mux config, CONFIG_DAVINCI_MUX.

    The debug interface is new to me. Definitely note that for future reference. At this rate, forum posts are the documentation.

  • 0 in reply to Norman Wong
    Intellectual 320 points

    That is interesting. I'm currently hacking TI linux kernel 2.6.37, as part of the AM3517 EVM BSP 4.0.2. I'm trying to get McSPI bus #1 to work. No luck so far. Now I'm trying to do something simpler, like toggling a single discrete output - no luck there either. I'm know C/C++, but a noob kernel hacker so I'm always afraid of missing a step here and there...

    In my efforts to get McSPI / GPIO to work, I tried to configure the i/o pads with the help of TI's PinMux utility, re-compiled u-boot and verified pin definitions as mentioned in this post. After verifications, it looks like the kernel actually overrides the pad definitions because the pins I reserved for GPIO are not set.

    I've noticed the CONFIG_OMAP_MUX option in the kernel build configuration and didn't try to disable it for GPIO testing. If it does what it says then I expect u-boot configuration to show up next time. 

    Indeed, AM3517 configuration is a frustrating experience for noobs and the kernel OMAP mux source files look like a kludge of OMAP2 & OMAP3 features. Quite confusing for now, but I'm sure I'll get the hang of it.

    Cheers,

    Yves McDonald

     

     

     

  • 0 in reply to Yves McDonald
    Prodigy 80 points

    Yves,

     

    I had similar problems with configuring the mux from Linux. Here's a patch that adds full ZCN package support:.

    http://marc.info/?l=linux-omap&m=130997114621564&w=2

     

    Best regards,

    Raphaël Assénat

  • 0 in reply to Raphaël Assénat
    Intellectual 320 points

    Merci,

    I will look at it closely...

    Okay, I applied the patches, configured pads through Pin Mux utility, rebuilt u-Boot with the files provided by Pin Mux and re-compiled the Linux kernel as per instructions and it works!

    Here's one more file I had to modify: in ~/arch/arm/mach-omap2/Kconfig, I changed package type from CBB to ZCN to have the appropriate pin mapping built into the kernel. Here's how it looks now:

    config MACH_OMAP3517EVM

    bool "OMAP3517/ AM3517 EVM board"

    depends on ARCH_OMAP3

    default y

    select OMAP_PACKAGE_ZCN

    Without that, the package selection would remain 'CBB'.

    Once again, thanks for the patches,

     

    Yves McDonald