So I've already had some build issues that you guys have helped out with - perhaps you can also solve what will hopefully be the last remaining problem on this setup. I'm working with an OMAP3530 using linux 02.01.03.11 and trying to get the v2.01.03.11-WL6.1.3.1 software (patched to use 2008q1 toolchain) working on a setup that is hardware-equivalent to the Mistral WLAN daughter card.
Everything is building now (hooray) and I'm able to insmod the modules (yay!), but ifconfig is not able to bring the interface up.
Here's the process:
root@omap3evm:~/wlan/wlan# insmod sdio.ko
root@omap3evm:~/wlan/wlan# insmod bmtrace.ko
root@omap3evm:~/wlan/wlan# insmod tiwlan_drv.ko
tiwlan0 (): not using net_device_ops yet
Old CONTROL_PADCONF_UART1_CTS value = 0x01000110
Old CONTROL_PADCONF_UART1_RTS value = 0x00000000
New CONTROL_PADCONF_UART1_CTS value = 0x01000104
New CONTROL_PADCONF_UART1_RTS value = 0x011c0000
GPIO-150 autorequested
Inside hPlatform_DevicePowerOff()
root@omap3evm:~/wlan/wlan# ./tiwlan_loader
root@omap3evm:~/wlan/wlan# ifconfig tiwlan0 10.1.100.56 netmask 255.255.255.0 up
ifconfig: SIOCSIFFLAGS: Cannot assign requested address
Running ifconfig -a shows the following for tiwlan0:
tiwlan0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:10.1.100.56 Bcast:10.255.255.255 Mask:255.0.0.0 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
tiwlan0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:10.1.100.56 Bcast:10.255.255.255 Mask:255.0.0.0
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
I'm concerned that there is no MAC address assigned - that looks like a likely problem to me - does the loader take care of that automatically, or is that something I need to specify myself somehow? Any other thoughts on what the issue might be?
Err, actually that ifconfig output looks like this (with the right netmask):
tiwlan0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:10.1.100.56 Bcast:10.1.100.255 Mask:255.255.255.0 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
inet addr:10.1.100.56 Bcast:10.1.100.255 Mask:255.255.255.0
Hi Glenn,
Please let me know what does happen to 'ifconfig tiwan0 up after running tiwlan_loader', whether firmware is downloaded or not?
If SDIO interface is fine, it will read chip-id and download the firmware. To get more debug messages run 'dmesg' and verify whether firmware is downloaded or not?
Thanks,
Sinoj
Running 'ifconfig tiwlan0 up' just gives the 'Cannot assign requested address' message that I posted above. There is nothing in dmesg except what I already posted... which is odd, because looking at the source, there are a lot of status messages that I should be seeing. I'll see about adding a few more debug messages in the initialization and see where it's stopping. Thanks for the hint - let's see if that's enough to get me going.
For some reason, the 'os_error_printf' calls weren't outputting to screen or to dmesg. Go figure. Replacing those with simple printf's allowed me to see what was going on inside... and it's getting to the end of init_driver without any errors. Is there a way to verify that the device does actually have the firmware loaded like the loader claimed to do?
It looks like the problem is that ndo_validate_addr is being set to the wrong function. Somehow, it's being set to dev->set_multicast_list instead of dev->validate_addr. The structures in netdevice.h look equivalent, so I'm not sure how that's happening. Still investigating, but I was wondering if that clue jars loose any ideas here.
So, indeed, manually setting up the netdev_ops structure instead of relying on dev.c to simply assign dev->netdev_ops to &dev->init means that the correct function pointers are now being assigned... and we don't get a MAC address verification failure.
Now, I am able to get some activity in the driver when I call ifconfig:
root@omap3evm:~/WL1271_demo_01/wlan# ifconfig tiwlan0 10.1.100.56 netmask 255.25
5.255.0 up
wlanDrvIf_Start()
Before drvMain_InsertAction()
Inside drvMain_InvokeAction()
drvMain_Sm(): State = 0, Event = 0
drvMain_Sm(): State = 1, Event = 1
Inside drvMain_SetDefaults()
pInitParams->RoamingScanning_2_4G_enable 0
Inside hPlatform_DevicePowerOn()
drvMain_Sm(): State = 2, Event = 2
@@@ enable_mmc_power() 2
setting SDIO F&I clock Configuration
done setting SDIO F&I clock Configuration
SDIO clock Configuration is now set to 24Mhz
After sdioDrv_ConnectBus, iStatus=0
After SD_IO_GO_IDLE_STATE, iStatus=0
sdioDrv_ExecuteCmd() SDIO Command error status = 0x18000
After VDD_VOLTAGE_WINDOW, iStatus=-1
Try to SDBus Connect again...
It appears to get to the point where it sends the initialization stream, and I can verify that there is activity on the clock for a short period of time, but the MMCHS_STAT.CC bit does not appear to be set before we time out. It then attempts to re-connect, and we alternate several times between an request_irq failure and the failure above until it finally quits.
sdioDrv_InitHw() - request_irq FAILED!!
After sdioDrv_ConnectBus, iStatus=-16
...snip...
[WLAN] Exit application
Before netif_start_queue()
Leaving wlanDrvIf_Start()
Any thoughts on what the issue might be?
From the above log it seems that SDIO inteface is not behaving properly. Please follow the below procedure to test SDIO interface.
Commands:
# insmod sdio.ko
# insmod testsdio.ko (available under "external_drivers/omap3530/Linux/sdio/" after build the driver)
# echo i > /proc/sdio_test (Initializing the SDIO interface and it will provide the CHIP id)
#echo cs > /proc/sdio_test
This above command will transmit the 64 to 512 byte data over the SDIO interface and check the success of data transmission.
Please verify the SDIO inteface, wheather it is working properly.
Could you please try the pre-built binaries (uImage and wlan) available in v2.01.03.11-WL6.1.3.1 package? Is it possible to run on your set up?That will help us in identifying whether the problem is build issue or hardware issue.
Thank you guys for the excellent suggestions. So, I'm using now only the pre-built kernel image and driver package. Running the sdio test, I get an error similar to the one I saw before. In sdioDrv_ExecuteCmd(), it sends a command and then checks the Command Complete bit to see that it sent... and we get nothing.
Full error text:
root@omap3evm:~/v2.01.03.11-WL6.1.3.1/wlan# insmod sdio.ko
root@omap3evm:~/v2.01.03.11-WL6.1.3.1/wlan# insmod testsdio.ko
OMAP3430_Wlan_Hardware_Init start
OMAP3430_Wlan_Hardware_Init() enter
Configuring OMAP3530 pin MUX
OMAP3430_Wlan_Hardware_Init() exit
OMAP3430_Wlan_Hardware_Init - SUCCESS
OMAP3430_TNETW_HardReset start
OMAP3430_TNETW_Power(-OFF-)
OMAP3430_TNETW_Power(-ON-)
OMAP3430_TNETW_HardReset - SUCCESS
sdio_test_module_init: SDIO Test Reset OK
sdio_test_module_init: OK
root@omap3evm:~/v2.01.03.11-WL6.1.3.1/wlan# echo i > /proc/sdio_test
sdioDrv_ExecuteCmd() SDIO Command error status = 0x18000 //First error here
In sdio_test_init: going to perform set_partition. mem size = 0x16800, mem addr =
0x0, reg size = 0x8800, reg addr = 0x300000
Running set_partition status = sdioDrv_WriteSyncBytes() SDIO Command error status
= 0x18000
-1 NOT OK
sdioDrv_ReadSyncBytes() SDIO Command error status = 0x18000
Read device ID via ReadByte: 0x0
sdiodrv_send_data_xfer_commad() SDIO Command error! STAT = 0x18010
sdiodrv_data_xfer_sync() buffer disabled! length = 4 BLK = 0x4 PSTATE = 0x0
sdioDrv_WriteSync() FAILED!!
sdiodrv_send_data_xfer_commad() SDIO Command error! STAT = 0x18000
It looks like a hardware issue. You need to verify the SDIO connectivity and check whether WLAN chip is powered on or not.
Also, could you please tell us about your setup/platform? Is that MMC2 on omap3530? and which GPIO is used for WL_EN?
Regards,
It is MMC2 on OMAP3530. The WL_EN pin is currently not under GPIO control, but is hooked up to a jumper that is pulling it high (and I can manually switch it to low). I can verify clock signals going over the clock pin and that something is changing in the CMD line while those clock signals are running. Does WL_EN need to be connected to a GPIO? Is there anything else that I can test that would be helpful?
The WL_EN is not necessarily to be GPIO. echo i > /proc/sdio_test is the best way of validating the hardware from driver.
Also, you can try to reduce interface clock rate to some lower value (6Mhz) in SdioDrv.c and use it.
6Mhz clock doesn't seem to change any behavior. Looking at the output above though... the point where it fails is not the first command sent across the interface. It completes sdioDrv_InitHw successfully, and it sends the SD_IO_GO_IDLE_STATE command successfully, but then it fails on VDD_VOLTAGE_WINDOW. So it's not that it can't execute any commands... any idea what VDD_VOLTAGE_WINDOW does - maybe that might give a clue?
For SD_IO_GO_IDLE_STATE command we do not expect any response from SD card. VDD_VOLTAGE_WINDOW is the first command that the host expect some response from the device. It is about the voltage range that card can support. Here, it looks like card/device does not respond to that command at all.
I knew it would be something simple and stupid, but I didn't think it would be this stupid. Going over the connections to the board again for the half-dozenth time, we noticed that the power source jumper wasn't set to DC. Isn't that always what happens...
Thank you guys again for your excellent help. Hopefully that was the last hurdle.