I’ve made my changes to kernel file board-am335xevm.c (I based my changes on the wireless support already there for the EVM board). I’ve installed the wl1271 chip firmware (opkg install linux-firmware-wl12xx). Now when the beaglebone boots, or when I issue “ifup wlan0”, I get these dmesg errors:
It appears that the wl1271 driver is attempting to write the firmware to the wl1271 chip, but it’s failing.
When I issue “ifup wlan0” and use a scope to probe the pins, I see the WLAN enable pin go high, I see pulses on the SDIO clock pin, and I see pulses on the four SDIO data lines, so it appears the driver is trying to communicate with the chip.
Where is the chip id 0x66666666 coming from? Is that just a default value the driver reports when it can’t read the chip?
Is there a way to turn on verbose debugging in the Wl1271 driver so I can get better debugging information?
Any ideas about what might be wrong would be appreciated.
Thanks,
Tim
PS I’m using the TiWi-R2 transceiver chip from LS Research, which has a WL1271 under the hood.
I’ve made my changes to kernel file board-am335xevm.c (I based my changes on the wireless support already there for the EVM board). I’ve installed the wl1271 chip firmware (opkg install linux-firmware-wl12xx). Now when the beaglebone boots, or when I issue “ifup wlan0”, I get these dmesg errors:
It appears that the wl1271 driver is attempting to write the firmware to the wl1271 chip, but it’s failing.
When I issue “ifup wlan0” and use a scope to probe the pins, I see the WLAN enable pin go high, I see pulses on the SDIO clock pin, and I see pulses on the four SDIO data lines, so it appears the driver is trying to communicate with the chip.
What MMC port are you using? Double check your pin mux for all the MMC pins by doing a ‘cat’ on the related pins in /sys/kernel/debug/omap_mux. It could be that one of your SDIO data lines is configured for the wrong mode.
Where is the chip id 0x66666666 coming from? Is that just a default value the driver reports when it can’t read the chip?
I’m not sure about the 0x66666666, but the -84 error is -EILSEQ (illegal byte sequence). You may want to debug the actual cause of the error by looking at the HSMMC driver (drivers/mmc/host/omap_hsmmc.c). If you have dynamic debugging enabled, you could display the dev_dbg() calls, or just insert printk() statements yourself. In omap_hsmmc_do_irq(), the interrupt handler checks the state of the STAT register. This tells you whether there was a CRC error on the bus. See the AM335x TRM 18.5.1.19 for details.
Is there a way to turn on verbose debugging in the Wl1271 driver so I can get better debugging information?
The WL12xx driver does have a wl12xx_debug_level module parameter that you can use:
modprobe wl12xx debug_level=0xffffffff
Check out /sys/kernel/debug/ieee80211/phy0/wl12xx as well.
struct wl12xx_platform_data {
void (set_power)(bool enable);
/ SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
int irq;
bool use_eeprom;
int board_ref_clock;
int board_tcxo_clock;
unsigned long platform_quirks;
int bt_enable_gpio;
int wlan_enable_gpio;
};
I have a few questions.
What is board_ref_clock? Is this the frequency of the SDIO_CLK going to the TiWi chip?
What is board_tcxo_clock? I don’t set this to anything? Should I?
How does WL12XX_REFCLOCK_38_XTAL differ from WL12XX_REFCLOCK_38?
And finally, what is use_eeprom? I don’t set this to anything either.
Note : My code in board-am335xevm.c mimics the code that is already in this file supporting the WL1271 chip on the am335x eval board.