From: beagl...@googlegroups.com [mailto:beagl...@googlegroups.com] On Behalf Of Tim M
Sent: Wednesday, August 15, 2012 1:12 PM
To: beagl...@googlegroups.com
Subject: [beagleboard] Trying to get wireless (WL1271) driver working on Beaglebone
We've built a cape board containing a TiWi-R2 transceiver chip from LS Research. This chip has a WL1271 chip under the hood. We are using this cape board on a Beaglebone Rev A3. We are using the Angstrom distribution.
I'm trying to get WLAN working on this system. The host processor talks to the WL1271 chip over an SDIO interface. This is what I've done so far:
1. I've configured the pin mux for the appropriate pins by writing to the appropriate "magic" files, for example:
echo 0x36 > /sys/kernel/debug/omap_mux/gpmc_wait
2. I've recompiled the Angstrom kernel, and I've loaded the kernel module wl12xx_sdio.ko, along with the following modules on which wl12xx_sdio.ko depends: wl12xx.ko, mac80211.ko, cfg80211.ko, rfkill.ko.
Have I loaded the correct kernel modules to support WLAN? Am I missing some module? When I load these kernel modules (using modprobe) I don't see any WLAN-related messages in the dmesg output.
I thought I would have to specify parameters to the wl12xx_sdio driver telling it which WLAN IRQ to use and which SDIO interface to use (SDIO0, SDIO1, etc), but none of these modules support such parameters.
I have the feeling I'm missing something. I've been doing google searches and searching the beagleboard. I've found this topic:
http://groups.google.com/group/beagleboard/browse_thread/thread/8f12c1e69d644e86
This topic leads me to believe that I have to add support for the WL1271 chip to the kernel file arch/arm/mach-omap2/board-omap3beagle.c. Am I right?
Any help on what I'm doing wrong, or what I should be doing, would be greatly appreciated.
Hi Tim,
It’s been a while since I worked on getting WL1271 working on the Beagle-xM, but from what I recall, if you are able to get the wl12xx_sdio kernel module loaded, then the problem is probably with wpa_supplicant. I recall that dbus did not launch wpa_supplicant correctly so I killed off the dbus (wpa_supplicant) process that started wpa_supplicant manually. If you do this correctly, you will find a wlan0 network interface and you should be up and running. Make sure you have a wifi.config file setup for connman with your wpa_supplicant settings. You might have to restart connman with systemctl restart connman.service.
Regards,
John
Tim M
-- To join: http://beagleboard.org/discuss
To unsubscribe from this group, send email to:
beagleboard...@googlegroups.com
Frequently asked questions: http://beagleboard.org/faq
Hi Tim,
If you don’t want Angstrom to delete the source code, comment out the “rm_work” line in <oe-folder>/config/local.conf file like this:
# INHERIT += “rm_work”
After building the kernel, you will find the source code in <oe-folder>/build/tmp-angstrom_v2012_05_eglibc/work/beaglebone-angstrom-linux-gnueabi/linux-mainline-3.xx.xx/git
Alternatively, you could always use Robert’s and Koen’s Beagleboard kernel script to build everything you need. Simply clone git://github.com/beagleboard/kernel.git, checkout the branch you need and run the patch.sh script. This will give you everything you need.
Regards,
John
Remove rm_work - Very "smart" advice! And in addition to necessary 500MB of sources you will have 6-25GB of binary objects and all temporary stuff that is built just in case..
From: beagl...@googlegroups.com [mailto:beagl...@googlegroups.com] On Behalf Of Maxim Podbereznyy
Sent: Friday, August 17, 2012 11:43 AM
To: beagl...@googlegroups.com
Subject: RE: [beagleboard] Re: Trying to get wireless (WL1271) driver working on Beaglebone
Remove rm_work - Very "smart" advice! And in addition to necessary 500MB of sources you will have 6-25GB of binary objects and all temporary stuff that is built just in case..
Why is this a problem? Disk drives are cheap ;-)
Thanks for your help so far guys.
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:
[ 36.793884] wl1271: ERROR sdio read failed (-84)
[ 36.798706] wl1271: WARNING unsupported chip id: 0x66666666
[ 37.163879] wl1271: ERROR sdio read failed (-84)
[ 37.168701] wl1271: WARNING unsupported chip id: 0x66666666
[ 37.533843] wl1271: ERROR sdio read failed (-84)
[ 37.538665] wl1271: WARNING unsupported chip id: 0x66666666
[ 37.550109] wl1271: ERROR firmware boot failed despite 3 retries
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.
--
Hi Tim,This might seem a bit left field, but there are specific voltage requirements for the SDIO on the TiWi-R2 chip - it needs to be run at 1V8. There are 6 different I/O banks on the AM335x... in the beagle bone, each with their own power feeds from the power supply chip. The beaglebone layout currently has all I/O banks supplied with 3V3 which obviously presents us with a serious issue in terms of getting SDIO comms to work with the TiWi chip. I think one of the major challenges faced in getting the beaglebone wifi cape production ready is/has been finding a way to successfully level-shift the 3V3 from the main processor to 1V8 on the TiWi - although by the sounds of it they have this figured out and are about to release it. For our own design we've set the power feed to the SDIO port to 1V8 in order to avoid this issue, although we're currently on a lead time of around a month and a half to get our own pcb populated and ready to go, so I am planning on getting a cape as soon as they are available to at least get some kind of proof of concept going asap.In terms of your own cape design it sounds like you may need to find out how this level shifting has been achieved on the soon to be released cape - or just wait for the cape and go from there - I imagine they won't release the schematic till it's rolling off the production line.Let us know if you have any luck in the mean time - we're certainly in the same boat, but haven't any hardware to get stuck on yet :)Regards,Andrew.
--
Pin mux is probably fine, but about pullups and directions? They matter too
--