Bug 1006194 - No firmware loading on older kernels
No firmware loading on older kernels
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
19
arm Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-10 03:58 EDT by Marcin Juszkiewicz
Modified: 2013-09-10 07:57 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-10 04:54:24 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Marcin Juszkiewicz 2013-09-10 03:58:34 EDT
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 Harald Hoyer 2013-09-10 04:05:13 EDT
what is old?
Comment 2 Marcin Juszkiewicz 2013-09-10 04:06:56 EDT
Ops, sorry.

Description of problem:
 
I use Fedora 19 on Samsung ARM Chromebook with 3.4 kernel from ChromeOS project (but my own compilation to follow Fedora kernel configuration). The problem is that firmware files are not loaded so I do not have WiFi and Bluetooth working.

Proper firmware files are present in rootfs.
 
Version-Release number of selected component (if applicable):

systemd 204-9.fc19
kernel 3.4

How reproducible:

Always
 
Steps to Reproduce:
1. boot Fedora 19 on Samsung ARM Chromebook
2. sudo modprobe mwifiex_sdio
3. ifconfig mlan0
4. dmesg|tail
 
Actual results:

mlan0: error fetching interface information: Device not found

[  124.642496] mwifiex_sdio mmc2:0001:1: Failed to get firmware mrvl/sd8797_uapsta.bin
[  244.740998] mwifiex_sdio mmc2:0001:1: GET_CMD_NODE: cmd node not available
[  244.741135] mwifiex_sdio mmc2:0001:1: PREP_CMD: no free cmd node
[  244.741250] mwifiex_sdio mmc2:0001:1: GET_CMD_NODE: cmd node not available
[  244.741428] mwifiex_sdio mmc2:0001:1: PREP_CMD: no free cmd node
[  356.321209] mwifiex_sdio mmc2:0001:1: Failed to get firmware mrvl/sd8797_uapsta.bin
[  356.322169] mwifiex_sdio mmc2:0001:1: GET_CMD_NODE: cmd node not available
[  356.322928] mwifiex_sdio mmc2:0001:1: PREP_CMD: no free cmd node
[  356.323579] mwifiex_sdio mmc2:0001:1: GET_CMD_NODE: cmd node not available
[  356.324304] mwifiex_sdio mmc2:0001:1: PREP_CMD: no free cmd node

 
Expected results:

mlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

[ 2637.707673] mwifiex_sdio mmc2:0001:1: WLAN FW is active
[ 2637.993721] mwifiex_sdio mmc2:0001:1: ignoring F/W country code US
[ 2637.999600] mwifiex_sdio mmc2:0001:1: driver_version = mwifiex 1.0 (14.66.11.p151)
Comment 3 Marcin Juszkiewicz 2013-09-10 04:26:13 EDT
I followed https://lists.fedoraproject.org/pipermail/arm/2013-June/006116.html and recompiled systemd with --with-firmware-path option so it works now.

But this is just to next systemd update ;(
Comment 4 Michal Schmidt 2013-09-10 04:54:24 EDT
Fedora 19 was released with Linux 3.9.5. Any package in the distribution may depend on functionality of that kernel version. Running F19 userspace on older kernels is not something we ever test or support. If you customize the kernel on your system, you may as well have a customized build of systemd. We are not going to add --with-firmware-path to official F19 systemd builds.
Comment 5 Marcin Juszkiewicz 2013-09-10 06:15:51 EDT
Thanks for answer.
Comment 6 Zbigniew Jędrzejewski-Szmek 2013-09-10 07:29:54 EDT
Yeah, compiling Fedora systemd package with --with-firmware-path= is not really an option. Are there any chances of the chromebook working with a mainline kernel?
Comment 7 Marcin Juszkiewicz 2013-09-10 07:40:38 EDT
You can boot and use ARM Chromebook with mainline kernel. 

But no audio, wifi, usb 3.0 and several other things.
Comment 8 Kay Sievers 2013-09-10 07:57:47 EDT
The simplest option might be to backport the in-kernel firmware loader to the
kernel sources of the old kernel. It should be pretty simple to do that.

Note You need to log in before you can comment on or make changes to this bug.