Bug 1006194

Summary: No firmware loading on older kernels
Product: [Fedora] Fedora Reporter: Marcin Juszkiewicz <mjuszkie>
Component: systemdAssignee: systemd-maint
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: harald, johannbg, lnykryn, mschmidt, msekleta, plautrba, systemd-maint, vpavlin, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: arm   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-10 08:54:24 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Marcin Juszkiewicz 2013-09-10 07:58:34 UTC
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 08:05:13 UTC
what is old?

Comment 2 Marcin Juszkiewicz 2013-09-10 08:06:56 UTC
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 08:26:13 UTC
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 08:54:24 UTC
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 10:15:51 UTC
Thanks for answer.

Comment 6 Zbigniew Jędrzejewski-Szmek 2013-09-10 11:29:54 UTC
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 11:40:38 UTC
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 11:57:47 UTC
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.