Actions
Forum Thread Details
  • State Verified Answer
  • Replies 5 replies
  • Subscribers 316 subscribers
  • Views 323 views
  • Users 0 members are here
Related

Kernel Freeze on button press

Former Member

Hi,

I am configuring MIO50 push-button of zed as an interrupt in "gpio-keys" linux gpio driver. When I press the button the kernel freezes. The Xilinx kernel version is 3.17.0 (tagged as "xilinx-v2014.4").

I would really appreciate some suggestions on this issue.

Thanks.

  • 0

    Hi haris,

    What version of the Linux kernel are you using? 

    We have seen at least one case where use of the xilinx-v2014.4 release tagged kernel with gpio-keys on ZedBoard appears to hang upon a button press.  Waiting about a minute produces a self-detected CPU stall error message.

    Can you confirm whether or not you are seeing the same thing on your end and tell us which version of Linux kernel you are using?

    Regards,

    -Kevin

  • 0 in reply to zedhed

    Hi Kevin,

    Thank you for writing back. I am using "3.17.0" Xilinx kernel, however, I don't see any error message after the button press; the kernel just hangs.

    I would also like to share my gpio device tree bindings with you:

    gpio0: gpio@e000a000 {
    compatible = "xlnx,zynq-gpio-1.0";
    #gpio-cells = <2>;
    clocks = <&clkc 42>;
    emio-gpio-width = <64>;
    gpio-controller;
    interrupt-parent = <&intc>;
    interrupts = <0 20 4>;
    reg = <0xe000a000 0x1000>;
    t};

    gpio-keys {
    compatible = "gpio-keys";
    #address-cells = <1>;
    #size-cells = <0>;
    autorepeat;
    sw50 {
    label = "sw50";
    gpios = <&gpio0 50 0>;
    linux,code = <108>; /* down */
    gpio-key,wakeup;
    autorepeat;
    };
    sw51 {
    tlabel = "sw51";
            gpios = <&gpio0 51 0>;
            linux,code = <109>;
    tgpio-key,wakeup;
    tautorepeat;
        };tt
    };

  • 0 in reply to Former Member

    Hi haris,

    I asked around here at Avnet and it turns out that what you see does sound very similar to an issue that we ran into with another customer working with the xilinx-v2014.4 (3.17) release tag.

    The workaround is to compile the 3.17 kernel (xilinx-v2014.4 tag) with u2018gpio-zynq.cu2019 from the 3.15 repository (xilinx-v2014.3 tag) or just use the 3.15 kernel which doesnu2019t exhibit the behavior you are seeing. 

    From what I understand Xilinx has been made aware of the issue but the affected code comes from a change to the kernel made upstream which broke the behavior on Zynq for the xilinx-v2014.4 release.

    If you happen to get a chance to look into it further and find anything significant, it would be useful for the community if you share what you find with us.

    Regards,

    -Kevin

  • 0 in reply to zedhed

    Hi,

    Thanks for workaround, Kevin. It worked!. I will try looking into this issue and will surely let you guys know about it.
    Thanks.

  • 0 in reply to zedhed

    I'm using petalinux 2014.4 (kernel 3.17) and I had this same problem.  But instead of a button press I'm using MIO50 as a GPIO interrupt to the TI WiLink8 Wi-Fi module.  The driver would load but then the interrupt line would go high and stay there and after a minute or two the kernel would indicate that it stalled and print out a long stack trace.

    Compiling the 3.17 kernel with the gpio-zynq.c from the 3.15 repository (xilinx-v2014.3 tag) solved the problem.

    Prior to using MIO50, I was using MIO0 as the interrupt and it worked fine.  The problem looks like it's isolated to either the MIO50 pin itself or the gpio bank that contains it.