PaddleStroke Posted October 18, 2019 Posted October 18, 2019 Hi! Using mainline on custom A20 board with sch very close to lime2, with 2 differences: (- EMAC of lime instead of GMAC of lime2) - AP6210 wifi/bt module on MMC3 with same schematic as cubietruck. Only difference in AP6210 schematic is that : - we use PE1 for WIFI_Enable instead of PH9. - PE0 for wifi_host_wake instead of PH10. BT works OK. Wifi doesn't work. To test the wifi part, we used cubietruck DTS, only patching the parts about PH9 and PH10. BRCMFMAC load without any messages and iwconfig / ifcongif say there is no wireless card. "dmesg | grep brcmfmac" gives no results. nor "dmesg | grep ap6210". lsmod list brcmlmac and brcmutil as loaded. Tried rmmod and modprobe again but nothing happens. After seeing this patch : https://github.com/armbian/build/blob/master/patch/kernel/sunxi-dev/ARM-dts-sun7i-Disable-OOB-IRQ-for-brcm-wifi-on-Cubietruck-and-Banana-Pro.patch?fbclid=IwAR2ySqUILAuBSjIoag8lAmnXWwsZbrAMFpfEOpA9J5YEtAbSUQtFhqnBRAQ I tried removing those 3 lines again by d /boot/dtb sudo dtc -I dtb -O dts -o sun7i-a20-cubietruck.dts sun7i-a20-cubietruck.dtb nano sun7i-a20-cubietruck.dts removed the 3 lines, then sudo dtc -I dts -O dtb -o sun7i-a20-cubietruck.dtb sun7i-a20-cubietruck.dts But still the same Any ideas ?
martinayotte Posted October 18, 2019 Posted October 18, 2019 2 hours ago, PaddleStroke said: "dmesg | grep brcmfmac" gives no results First, try to do "dmesg | grep -i sdio" and then shorter your previous command to "dmesg | grep -i brcm". BTW, never do "modprobe brcmfmac", it should be loaded by the DT itself if properly set. Also, check the schematic, sometime "AP6212" are powered using GPIO controlled VBUS (like USB0) and sometime it requires also a 32KHz clock in DT.
PaddleStroke Posted October 23, 2019 Author Posted October 23, 2019 grep SDIO and BRCM don't return anything either. MMC return something though (see enclosed picture). It looks like an error what do you think? 1c12000 is the mmc3 1c0f0000 is the mmc0 (sd card) sunxi-mmc 1c12000.mmc: Linked as a consumer to regulator.2 sunxi-mmc 1c12000.mmc: Dropping the link to regulator.2 sunxi-mmc 1c12000.mmc: Linked as a consumer to regulator.2 sunxi-mmc 1c12000.mmc: Dropping the link to regulator.2 sunxi-mmc 1c12000.mmc: Linked as a consumer to regulator.2 sunxi-mmc 1c12000.mmc: Dropping the link to regulator.2 sunxi-mmc 1c12000.mmc: allocated mmc-pwrseq sunxi-mmc 1c12000.mmc: initialized, max. request size: 16384KB looks like it's trying several time something without success? About the GPIO enable, there is indeed one. On cubietruck it's PH9 and on our board it's PE1. So we modified the dts accordingly but it doesn't seem to help. About the clock we use the cubietruck image with modified DTS just to enable the PE1 instead of PH9. So the clock (PI12) should be setup correctly as schematic match. A20_Cubietruck_HW_V10_130606.pdf
PaddleStroke Posted October 23, 2019 Author Posted October 23, 2019 Ok I could get the wifi working by wiring manually the WIFI_EN pin directly to 3V3. Apparantly the PE1 was not turning on and always kept at 0V (reading from multimeter). Not sure why. Now iwconfig show the card in wlan0. I think maybe the wifi is just off by default when booting up? Then we have to enable it manually with a command? Do you know if a command enable/disable wifi?
martinayotte Posted October 23, 2019 Posted October 23, 2019 8 minutes ago, PaddleStroke said: Ok I could get the wifi working by wiring manually the WIFI_EN pin directly to 3V3. Apparantly the PE1 was not turning on and always kept at 0V (reading from multimeter). Do you mean that you turned ON the GPIO using sysfs or did you had to wire an 3V3 connection externally ? 13 minutes ago, PaddleStroke said: Not sure why. Me neither, mmc-pwrseq should have bring a high level on this PE1. Can you check /sys/kernel/debug/gpio ?
PaddleStroke Posted October 24, 2019 Author Posted October 24, 2019 I hand connected a wire from 3v3 to wifi_en Do you know where I can find a table of the GPIO number? Alternatively do you think problem could be in uboot ? Maybe we have not patched correctly uboot dts Or maybe it's the E gpio the problem? Maybe they are used by something else? Or maybe some hardware issue ?
martinayotte Posted October 24, 2019 Posted October 24, 2019 19 minutes ago, PaddleStroke said: Do you know where I can find a table of the GPIO number? AllWinner SoC are using simple formula for numbering : (position of letter in alphabet - 1) * 32 + pin number This is taken from https://linux-sunxi.org/GPIO 21 minutes ago, PaddleStroke said: I hand soldered a wire from 3v3 to wifi_en I hope your soldering didn't broke the GPIO itself with this short, because PE1 is effectively GPIO129 shown in you screenshot as "output" been "low" level. Why is it "low" ? Your DT should have bringing "high" after the reset been done since "reset-gpios" is defined as ACTIVE_LOW. You can try to comment "reset-gpios" temporarily, remove your wire, and try to bring it "high" using gpio sysfs.
PaddleStroke Posted October 25, 2019 Author Posted October 25, 2019 Quote I hope your soldering didn't broke the GPIO itself I hand soldered PE1 to WIFI_EN. I wondered if I have not burned something on AP6210 side because it was really hard to solder a wire to the AP6210 pin. But because the wifi can be hand-booted by connecting a wire between 3v3 and WIFI_EN I guess the enable pin still work. On the SoC side I don't think it could have burned because it's far from SoC and trace is very small (0.127mm), so very little heat should have gone up. So overall I don't think anything burnt I wonder maybe if the PE1 is maybe setup by default to do something else. Maybe it's use is overwriten by something else? I will try to replace this PE1 by another port. PH17 maybe. About why it's low I have no clue... The DTS of cubietruck say: mmc3_pwrseq: mmc3_pwrseq { compatible = "mmc-pwrseq-simple"; pinctrl-names = "default"; pinctrl-0 = <&mmc3_pwrseq_pin_cubietruck>; reset-gpios = <&pio 7 9 GPIO_ACTIVE_LOW>; /* PH9 WIFI_EN */ }; Why GPIO_ACTIVE_LOW ? It's normal for a reset-GPIO? Btw is this the correct way to edit a dtb? Prefer double checking ! cd /boot/dtb sudo dtc -I dtb -O dts -o sun7i-a20-cubietruck.dts sun7i-a20-cubietruck.dtb // DTB to DTS nano sun7i-a20-cubietruck.dts //edit DTS sudo dtc -I dts -O dtb -o sun7i-a20-cubietruck.dtb sun7i-a20-cubietruck.dts //DTS to DTB
PaddleStroke Posted October 25, 2019 Author Posted October 25, 2019 I don't understand what is this "mmc-pwrseq-simple" I read this but still don't understand... The WL_REG_ON is not a reset pin. It seems it's just a Enable pin. So it should just be high. I tried changing the GPIO assigned to PC18. Before doing so I checked multimeter said 3.3V, this pin was high by default. Now after reboot the pin goes low right after booting kernel and stays low. If I understand correctly this : compatible = "mmc-pwrseq-simple"; reset-gpios = <&pio 7 9 GPIO_ACTIVE_LOW>; /* PH9 WIFI_EN */ Will asserted (means activate right?) the GPIO PH9 to low before powering up the MMC. Then after boot it should be deactivated. Does it means it will go back to default or that it will go back to the countrary of GPIO_ACTIVE_LOW so high? If so in my case it does not go back to high. Does it means the card is not confirmed powered ON by the SoC?
PaddleStroke Posted October 25, 2019 Author Posted October 25, 2019 Ok if I recall correctly armbian use the megous fork of torvals right? If so there are lot of difference in cubietruck DTS. It does not look right : Megous fork : mmc3_pwrseq: mmc3_pwrseq { compatible = "mmc-pwrseq-simple"; pinctrl-names = "default"; pinctrl-0 = <&mmc3_pwrseq_pin_cubietruck>; reset-gpios = <&pio 7 9 GPIO_ACTIVE_LOW>; /* PH9 WIFI_EN */ }; &pio { ... mmc3_pwrseq_pin_cubietruck: mmc3_pwrseq_pin@0 { pins = "PH9"; function = "gpio_out"; }; ... Torvalds github : mmc3_pwrseq: mmc3_pwrseq { compatible = "mmc-pwrseq-simple"; reset-gpios = <&pio 7 9 GPIO_ACTIVE_LOW>; /* PH9 WIFI_EN */ clocks = <&ccu CLK_OUT_A>; clock-names = "ext_clock"; }; &pio { /* Pin outputs low power clock for WiFi and BT */ pinctrl-0 = <&clk_out_a_pin>; pinctrl-names = "default"; }; Torvalds github A20 DTSI : pio: pinctrl@1c20800 { ... /omit-if-no-ref/ clk_out_a_pin: clk-out-a-pin { pins = "PI12"; function = "clk_out_a"; }; ... Why megous fork don't mention the PI12 external clock...? Now the Torvalds github also seem to have a problem. Why he makes &pio modifications like this? It should not be more like this? : &pio { clk_out_a_pin: clk-out-a-pin { pins = "PI12"; function = "clk_out_a"; } Or not &pio and something else... But doing as it's done in cubietruck dts it seems wrong. What do you think?
martinayotte Posted October 25, 2019 Posted October 25, 2019 5 minutes ago, PaddleStroke said: Why megous fork don't mention the PI12 external clock...? Because maybe this clock is only used in bluetooth, I'm not sure ... Did you have the clock in your previous success ? 52 minutes ago, PaddleStroke said: I don't understand what is this "mmc-pwrseq-simple" I read this but still don't understand... The WL_REG_ON is not a reset pin. It seems it's just a Enable pin. So it should just be high. This is a general description : it is "active low reset", but this is equal to be "active high enable". So, it should be low only during a quick pulse and returns high for normal state. As I said above, you can try to comment the "reset-gpio" in DT and try to manually doing the low pulse using /sys/class/gpio. This would be only for testing purposes...
PaddleStroke Posted October 25, 2019 Author Posted October 25, 2019 No I did not have the clock in previous success. I think maybe because CLK is not connected the reset hang forever maybe? I think the clk is used by wifi too. The supplier of AP6210 told me so.
martinayotte Posted October 25, 2019 Posted October 25, 2019 2 minutes ago, PaddleStroke said: No I did not have the clock in previous success. I think maybe because CLK is not connected the reset hang forever maybe? I think the clk is used by wifi too. The supplier of AP6210 told me so. But you've said that you got the WiFi working, right ?
PaddleStroke Posted October 25, 2019 Author Posted October 25, 2019 Yes if the Enable pin is connected to 3v3 directly. The issue is that the PE1 to which enable pin is connected never go high. I suspect it's because the clock is not set but I'm not sure
martinayotte Posted October 25, 2019 Posted October 25, 2019 45 minutes ago, PaddleStroke said: Yes if the Enable pin is connected to 3v3 directly. This means that clock is not needed for WiFi. Did you tried the GPIO sysfs ?
PaddleStroke Posted October 25, 2019 Author Posted October 25, 2019 Finally it works as expected. I changed the GPIO to PC18 (which was high by default when I probed it before changing it in dts) First I tried to make modifications to match torvalds DTS with the PI12 CLK settings. But it wasn't working. In the end I just tried reset to megous settings, just changing the port to PC18 and it works. So it seems something is forcing PE1 to low.
martinayotte Posted October 25, 2019 Posted October 25, 2019 7 minutes ago, PaddleStroke said: So it seems something is forcing PE1 to low. Maybe the CSI, although it seems to be disabled by default in sun7i-a20.dtsi.
Recommended Posts