Actions
Forum Thread Details
  • State Not Answered
  • Replies 6 replies
  • Subscribers 329 subscribers
  • Views 1084 views
  • Users 0 members are here
Related

SDIO Wifi driver (AR6103) problem

Former Member

I am trying to use an Atheros AR6103 wifi module (SDIO interface) on the Zedboard.


As it is said on the Xilinx wiki website, the driver for the AR6103 is already part of the linux kernel,


here it is:  http://www.wiki.xilinx.com/Zynq+SDIO+WiFi  and http://wireless.kernel.org/en/users/Drivers/ath6kl.


The problem is that the wifi module comes in the forms of a SD card shape, but I have to use the SD slot on the Zedboard to boot the linux kernel.  If I use a Pmod to SD module to extend with one SD slot,  I have also to configure another SDIO controller in the PS using EMIOs to connect the Pmod.


What changes should I do if I want to use this integrated driver software in the Linux kernel ?  I know I have to regenerate the FSBL and bitstream.  What about the u-boot ? or any changes when building the linux kernel ?  Does the driver software automatically works with two SDIO controller ?


Thanks.


  • 0

    Hi doonny,

    You will need a new FSBL to enable the second SDIO controller and the updated bitstream to define the EMIO connections out to the Pmod connectors. An updated U-Boot should not be necessary.

    Assuming you have already built the kernel according to the Wiki page instructions to include the "ath6kl SDIO support" the only other change should be to your devicetree file.

    According to that Wiki page, it appears they are using the default ZC702 devicetree which contains this entry for the SDIO controller:

    ps7_sd_0: ps7-sdio@e0100000 {
    clock-frequency = <50000000>;
    clock-names = "clk_xin", "clk_ahb";
    clocks = <&clkc 21>, <&clkc 32>;
    compatible = "arasan,sdhci-8.9a";
    interrupt-parent = <&ps7_scugic_0>;
    interrupts = <0 24 4>; reg = <0xe0100000 0x1000>;
    xlnx,has-cd = <0x1>;
    xlnx,has-power = <0x0>;
    xlnx,has-wp = <0x1>;
    } ;

    If you were to use the second Zynq PS SDIO controller but route the IO to EMIO and out to your PmodSD, you would need a second device entry to point to the second SDIO controller at address 0xE0101000 and it's dedicated interrupt channel.  Looking through the TRM, I see the following interrupt ID for SDIO1 so to calculate for the device tree, you would use (79 - 32 = 47).

    image

     

    Perhaps an entry like this would work?

    ps7_sd_1: ps7-sdio@e0101000 {
     clock-frequency = <50000000>;
     clock-names = "clk_xin", "clk_ahb";
     clocks = <&clkc 21>, <&clkc 32>;
     compatible = "arasan,sdhci-8.9a";
     interrupt-parent = <&ps7_scugic_0>;
     interrupts = <0 47 4>;
     reg = <0xe0101000 0x1000>;
     xlnx,has-cd = <0x1>;
     xlnx,has-power = <0x0>;
     xlnx,has-wp = <0x1>;
    } ;

    Regards,

    -Kevin

  • 0

    Thanks Kevin,

    I regenerated the devicetree.dtb/dts and checked out the files, the sd_1 configuration is just like your post.



    However, after booting, I got the following response:


    mmc1: Got command interrupt 0x00030000 even though no command operation was in progress.
    mmc1: Got command interrupt 0x00030000 even though no command operation was in progress.
    mmc1: Got command interrupt 0x00030000 even though no command operation was in progress.


    It seems that the kernel have detected the sd1 controller, but I can not find mmc1 under /dev. I am not sure what happened ? Thanks for your help.

  • 0

    PS: The following information are also shown on the termianl:



    mmc0: Invalid maximum block size, assuming 512 bytes
    mmc0: SDHCI controller on e0100000.ps7-sdio [e0100000.ps7-sdio] using ADMA
    mmc1: Invalid maximum block size, assuming 512 bytes
    mmc1: SDHCI controller on e0101000.ps7-sdio [e0101000.ps7-sdio] using ADMA





  • 0

    It seems that the kernel detected the interrupt signal from the SD controller, but could not find driver software to run ?  Am I right ?

  • 0

    SDIO controller output tristate signals are low active, so you have to invert them when connecting to IOBUFs, otherwise, connecting through EMIO wouldn't work. It is a bug.

  • 0

    I am working on a similar issue.  did you ever get this working?