Ubuntu
linux-linaro-omap package

some kernel config missing for wifi with IGEPv2 board (libertas driver finds no mmc interface)

Bug #709348 reported by [IDC]Dragon on 2011-01-28

This bug affects 3 people

Affects		Status	Importance	Assigned to	Milestone
	linux-linaro-omap (Ubuntu)	Confirmed	Undecided	John Rigby

Bug Description

The nice folks at #linaro IRC helped me to diagnose this so far and suggested to file a bug here.

I fail to get WiFi working, something in the kernel is missing. "modprobe libertas" resp. "modprobe libertas_sdio" is not probing the mmc bus and finding the SDIO hardware. "ifconfig -a" or "iwconfig" shows no wlan adapter for me.

I'm using Linaro on an IGEPv2 board, installed from these release files:
linaro-m-headless-tar-20101108-2.tar.gz
hwpack_linaro-igep_20101109-1_armel.tar.gz

uname -a reports:
Linux localhost.localdomain 2.6.35-1008-linaro-omap #15-Ubuntu Fri Oct 22 11:56:29 UTC 2010 armv7l GNU/Linux

lsb_release -rd reports:
Description: Ubuntu 10.10
Release: 10.10

apt-cache policy linux-image-2.6.35-1008-linaro-omap reports:
linux-image-2.6.35-1008-linaro-omap:
  Installed: 2.6.35-1008.15
  Candidate: 2.6.35-1008.15
  Version table:
*** 2.6.35-1008.15 0
        500 http://ports.ubuntu.com/ maverick-updates/universe armel Packages
        100 /var/lib/dpkg/status

When I issue "modprobe libertas", it generates this dmesg output:
[ 69.913543] lib80211: common routines for IEEE802.11 drivers
[ 69.913574] lib80211_crypt: registered algorithm 'NULL'
[ 70.059234] cfg80211: Calling CRDA to update world regulatory domain
[ 70.307250] cfg80211: World regulatory domain updated:
[ 70.307281] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 70.307281] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 70.307312] (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 70.307312] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 70.307342] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 70.307342] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)

When I issue "modprobe libertas_sdio", I get the following dmesg lines:
[ 169.514282] libertas_sdio: Libertas SDIO driver
[ 169.514312] libertas_sdio: Copyright Pierre Ossman

According to IRC user "agreen", there should appear something like this [ 2.536437] mmc1: new SDIO card at address 0001...

Tags:

Revision history for this message

[IDC]Dragon (idc-dragon) wrote on 2011-03-15:

The reason for this is an outdated IGEPv2 boardfile in the Linaro kernel tree. Pin multiplexer and/or voltage regulator are not set up to operate the WiFi hardware.
ISEE provides more recent boardfiles with their kernel.

Revision history for this message

[IDC]Dragon (idc-dragon) wrote on 2011-03-24:

This is the patch I got from ISEE. Edit (3.5 KiB, text/plain)

Here is the patch that solves it for kernel version 2.6.35-1010-linaro-omap, aka 2.6.35.9.

Other people had similar:
http://<email address hidden>/msg24125.html

Brian Murray (brian-murray) on 2011-03-24

tags:

added: patch

Revision history for this message

John Clark (myeventdata) wrote on 2011-03-31:

I am having the same issues with a variety of kernels. The symptoms are certainly identical. I have a REV C board that uses GPIOs 138 & 139 for wifi, and they are configured correctly.

[ 0.242706] IGEP2: Hardware Revision C (B-NON compatible)

GPIOs 128-159, gpio:
gpio-137 (GPIO_BT_NRESET ) out hi
gpio-138 (GPIO_WIFI_NPD ) out hi
gpio-139 (GPIO_WIFI_NRESET ) out hi

I have verified that the arch/arm/mach-omap2/board-igep0020.c board file contains the patch you speak of using kernel rev 2.6.35.11 from IGEP's website: http://downloads.igep.es/sources/linux-omap-2.6.35.11-0.tar.gz

The results are exactly as above. A modprobe libertas_sdio only prints the following dmesg entries:

[ 440.399200] cfg80211: Calling CRDA to update world regulatory domain
[ 440.494567] libertas_sdio: Libertas SDIO driver
[ 440.494598] libertas_sdio: Copyright Pierre Ossman

I have also tried these kernel revisions with the same identical behavior:

2.6.37.2-x3
2.6.37.5-x5
2.6.38.2-d8

Does anyone own an IGEPv2 _rev_C_ board with WiFi working?

Launchpad Janitor (janitor) on 2011-07-22

Changed in linux-linaro-omap (Ubuntu):
status:	New → Confirmed

Loïc Minier (lool) on 2011-08-01

Changed in linux-linaro-omap (Ubuntu):
assignee:	nobody → John Rigby (jcrigby)

Revision history for this message

[IDC]Dragon (idc-dragon) wrote on 2011-08-01:

I have something to add:
The patch I pointed to gave us first wifi contact, but suffers from low throughput, ~80kB/s. The reason is something like missing IRQ support for MMC.
Performance went to normal only after applying this patch, too:
http://git.igep.es/?p=pub/scm/linux-omap-2.6.git;a=commit;h=a6366004b99ebf0dc271548b11c971109ff49e0f

Revision history for this message

Adnan Jalaludin (adnan-singnet) wrote on 2011-11-15:

(.../u-boot/board/isee/igep0030/igep0030.h) for reference. Edit (16.3 KiB, text/plain)

I work with igep0030 modules only and do not have IGEPv2 (but I also toy around with BeagleC3 and overo). The igep0030 is similar to the IGEPv2 but has minor differences in the gpio/port usage.

On the igep0030, the mmc1 interface (and its sdio-based wifi) has failed detection since linux-3.0.0: I suspect the kernel's pin-init/re-init/muxing is not so good after linux-2.6.39.

But looking at the u-boot sources for the igep0030 from both IGEP and Linaro repositories, the pin-init file (.../u-boot/board/isee/igep0030/igep0030.h) were deficient compared to Beagle's and overo's. I have modified that file, rebuilt u-boot and, mmc1 (and the attached sdio-wifi) has started working again for the linux-3.0.9 (When possible, I'll try linux-3.1.1).

Linaro's git source for the IGEPv2 u-boot pin-init file (.../u-boot/board/isee/igep0020/igep0020.h) is also very basic, and a better one may be found int the IGEP repository (http://git.igep.es/?p=pub/scm/u-boot-arm.git;a=summary) but I can't test because I haven't an IGEPv2.

The attached u-boot pin-init file igep0030.h may have some issues because schematics aren't available for checking...

(The real fix should be in the kernel's pin reinit/muxing, but I hope the above helps).

Revision history for this message

Chase Qi (chase-qi) wrote on 2014-08-29:

Migrated to bugzilla: https://bugs.linaro.org/show_bug.cgi?id=560