I know I can disable it by compiling a new kernel without setting CONFIG_DRM_VMWGFX in config file. But I don't want build a new kernel, can I achieve it by modify some configurations?
I tried to delete vmwgfx.ko from the lib/modules/XXX/kernel/driver directory, then reboot, but the driver works well On Ubuntu 16.04. Why? Is the file elsewhere?
And I also tried to rmmod,but it's not work.
[root#ubuntu:] lsmod |grep vmwgfx
vmwgfx 235405 4
drm_kms_helper 159169 1 vmwgfx
ttm 99345 1 vmwgfx
drm 370825 7 ttm,drm_kms_helper,vmwgfx
[root#ubuntu:] rmmod -f vmwgfx
rmmod: ERROR: ../libkmod/libkmod-module.c:793 kmod_module_remove_module()
could not remove 'vmwgfx': Resource temporarily unavailable
[root#ubuntu:] modprobe -r vmwgfx
modprobe: FATAL: Module vmwgfx is in use.
Finally, I know how to do it.
The reason for my situation is that the driver's file is stored in initramfs-xxx.img. So we need to rebuild a initramfs-xxx.img.
find file path: modinfo vmwgfx
filename: /lib/modules/4.4.0-21-generic/kernel/drivers/gpu/drm/vmwgfx/vmwgfx.ko
version: 2.9.0.0
license: GPL and additional rights
description: Standalone drm driver for the VMware SVGA device
author: VMware Inc. and others
srcversion: AC179B70460E5C5D32AC416
alias: pci:v000015ADd00000405sv*sd*bc*sc*i*
depends: ttm,drm,drm_kms_helper
intree: Y
vermagic: 4.4.0-21-generic SMP mod_unload modversions
parm: enable_fbdev:Enable vmwgfx fbdev (int)
parm: force_dma_api:Force using the DMA API for TTM pages (int)
parm: restrict_iommu:Try to limit IOMMU usage for TTM pages (int)
parm: force_coherent:Force coherent TTM pages (int)
parm: restrict_dma_mask:Restrict DMA mask to 44 bits with IOMMU (int)
remove the driver file mv /lib/modules/$(uname -r)/kernel/driver/gpu/drm/vmwgfx/vmwgfx.ko /home/$(whoami)/.
backup your boot img: mv /boot/initrd.img-`uname -r` /home/`whoami`/
rebuld boot img: mkinitrd -f /boot/initrd.img-`uname -r` `uname -r`
reboot
If you want to remove other build-in driver file, this method works well.
If your vm is centos, just choose the correct file path and boot img name.
Related
Using Yocto-based tools, I'm able to generate several files for deployment. These involve:
sdimg file for writing to the SD card
A cpio.gz archive (Initramfs)
Image-initramfs.bin (Initramfs)
I would like to activate plymouth in my Embedded board (Raspberry Pi) with a Yocto-based Linux distribution. However I am not sure how to mount the cpio.gz archive or Image-initramfs.bin. I've read online that vanilla Raspbian has an entry in /config.txt in boot partition i.e. initramfs <file.gz> <start_address> and also a kernel command line option in /cmdline.txt in boot partition i.e. initrd=<file.gz>.
What I've tried so far involves both of these approaches. I copy the cpio.gz file to the /boot in root filesystem partition and configure the aforementioned files, which did not work. To break it down, here is how it looks:
+ Boot Partition
+ ---- overlays/
+ ---- config.txt
+ ---- cmdline.txt
+ ---- kernel.img
+ 1.2GB Volume (rootfs)
+ ---- bin/
+ ---- boot/
+--- <file>.cpio.gz
+ ---- var/
+ ---- usr/
....
Now, in config.txt, I have something like (tried many variations):
initramfs <file>.cpio.gz 0x00a00000
ramfsfile="<file>.cpio.gz"
ramfsaddr=0x00a00000
In cmdline.txt, I have:
initrd=<file>.cpio.gz dwc_otg.lpm_enable=0 console=serial0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
However, nothing is enough for the kernel to even give an error. That means, system boots up as normal, and there is no sign of initramfs usage.
Kernel that I compile with yocto is the following:
#> uname -a
#> Linux raspberrypi0-wifi 4.9.77-rt61 #11 PREEMPT RT Tue May 22 01:14:26 +03 2018 armv6l armv6l armv6l GNU/Linux
Following kernel config parameters are enabled:
#> modprobe configs
#> cat /proc/config.gz | gunzip > kernelconf.txt
...
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
I don't know what I'm missing here. Anything that catches your attention, please let me know. Any guidance is well appreciated.
I was able to boot into the initramfs by copying the resulting .cpio.gz archive to the boot partition of the sd card.
Then I've edited the config.txt option from
#initramfs initramf.gz 0x00800000
to
initramfs <name-of-the-copied-archive>.cpio.gz
After booting the raspberry it boots now into my initramfs image.
I am working on microzed 7010 board, I have manualy compiled kernel, u-boot, fsbl, and .bit (vivado). Board is booting well with all setup (without using petalinux). But i have noticed that kernel is not Uncompressing kernel... with zImage nor uImage. whereas i can see bootlogs with that of petalinux's images.
INPUT :
1 . zImage env is
zImage=tftpboot 0x3000000 zImage && tftpboot 0x2A00000 system.dtb && bootz 0x3000000 - 0x2A00000
2 . Boot log is =>
Zynq> run zImage
[2017-10-25 15:57:11
ethernet#e000b000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
[2017-10-25 15:57:15
Zynq> run zImage
[2017-10-25 15:57:22
Using ethernet#e000b000 device
TFTP from server 172.16.9.187; our IP address is 172.16.9.25
Filename 'zImage'.
Load address: 0x3000000
Loading:#####################################################################################################################################################################################################################################
3.9 MiB/s
done
Bytes transferred = 3913840 (3bb870 hex)
Using ethernet#e000b000 device
TFTP from server 172.16.9.187; our IP address is 172.16.9.25
Filename 'system.dtb'.
Load address: 0x2a00000
Loading: #
3.3 MiB/s
done
Bytes transferred = 13644 (354c hex)
Kernel image # 0x3000000 [ 0x000000 - 0x3bb870 ]
## Flattened Device Tree blob at 02a00000
Booting using the fdt blob at 0x2a00000
Loading Device Tree to 1fff9000, end 1ffff54b ... OK
Starting kernel ...
Booting Linux on physical CPU 0x0
Linux version 4.6.0-xilinx-00003-g2762bc9 (pritam#pritam) (gcc version 5.2.1 20151005 (Linaro GCC 5.2-2015.11-2) ) #3 SMP PREEMPT Wed Oct 25 10:28:387
[2017-10-25 15:57:24
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
3 . In u-boot I have given bootz support
4 . uImage is formed by
mkimage -A arm -O linux -T kernel -C none -a 0x10000000 -e 0x10000000 -n "Linux kernel" -d arch/arm/boot/zImage uImage
What causing it not to uncompress kernel ? Is u-boot compressing the kernel and booting ?
Any help will be appreciated.
Thanks and regards,
Pritam
Board is booting well with all setup (without using petalinux). But i have noticed that kernel is not Uncompressing kernel... with zImage nor uImage.
Some kernels can perform this step silently. The fact that you load a zImage (or a zImage in a uImage), and then see the Linux kernel version line means that the kernel has been uncompressed successfully and is executing
What causing it not to uncompress kernel ?
Your presumption that the kernel is not being uncompressed is simply wrong.
The zImage or uImage files that you are using are compressed kernel images. Since the kernel is actually executing (as evidenced by the boot log that you posted), the kernel must have silently uncompressed and proceeded to boot.
If the kernel did not uncompress (as you assert), then the kernel could not boot successfully (as you reported).
Is u-boot compressing the kernel and booting ?
No, U-Boot is not involved in uncompressing a zImage file.
A zImage is a self-extracting compressed Image file.
Depending on how the kernel was configured, the uncompression of the zImage file can be silent or verbose.
I have cloned the source codes from petalinux downloads. The boot logs, I got from images built by petalinux, shows Uncompressing kernel .... message. " Starting kernel ... Uncompressing Linux... done, booting the kernel. Booting Linux on physical CPU 0x0 Linux version 4.6.0-xilinx (pritam#pritam) (gcc version 5.2.1" So i am expecting it to show "uncompressing kernel " message
Using the same source code is only one requisite for building a duplicate kernel.
You also need to build with the same configuration.
The silent or verbose uncompression is selected by kernel configuration.
From arch/arm/Kconfig.debug:
menu "Kernel hacking"
...
config DEBUG_LL
bool "Kernel low-level debugging functions (read help!)"
depends on DEBUG_KERNEL
help
Say Y here to include definitions of printascii, printch, printhex
in the kernel. This is helpful if you are debugging code that
executes before the console is initialized.
Note that selecting this option will limit the kernel to a single
UART definition, as specified below. Attempting to boot the kernel
image on a different platform *will not work*, so this option should
not be enabled for kernels that are intended to be portable.
...
prompt "Kernel low-level debugging port"
...
config DEBUG_ZYNQ_UART0
bool "Kernel low-level debugging on Xilinx Zynq using UART0"
depends on ARCH_ZYNQ
help
Say Y here if you want the debug print routines to direct
their output to UART0 on the Zynq platform.
config DEBUG_ZYNQ_UART1
bool "Kernel low-level debugging on Xilinx Zynq using UART1"
depends on ARCH_ZYNQ
help
Say Y here if you want the debug print routines to direct
their output to UART1 on the Zynq platform.
If you expect a verbose uncompression, then you need to select CONFIG_DEBUG_KERNEL, CONFIG_DEBUG_LL, and an appropriate serial port.
ADDENDUM (response to comment)
Which one is better way to compress the kernel. zImage or gzipping arch/arm/Image ... are they same ... ???
What metric are you going to use to measure "better"?
In the end, the result is the same: a compressed kernel Image.
How many of these image files to you have to save?
How crucial is saving space and load times (if any) versus self-extraction?
In mkimage if I specified -C "gzip", I noticed that at time of loading image in ram, u-boot uncompresses the gzipped image ... !!!
As I already commented, that is a mislabeling of a zImage file, and therefore wrong. The zImage is self-extracting, and should be labeled as "uncompressed" so that U-Boot does not try to perform uncompression.
Interestingly I cannot duplicate your claim at the shell prompt. A zImage renamed to zImage.gz cannot be gunzip'd:
gzip: zImage.gz: not in gzip format.
More importantly, I cannot replicate the results that you claim you got.
=> bootm 20080000 - 22000000
## Booting kernel from Legacy Image at 20080000 ...
Image Name: Linux kernel
Image Type: ARM Linux Kernel Image (gzip compressed)
Data Size: 5774280 Bytes = 5.5 MiB
Load Address: 20008000
Entry Point: 20008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 22000000
Booting using the fdt blob at 0x22000000
Uncompressing Kernel Image ... Error: Bad gzipped data
gzip compressed: uncompress error -1
Must RESET board to recover
resetting ...
Does u-boot contains external decompresser ... ???
If you had bothered to read the link I had provided previously, the answer would be obvious.
U-Boot can be configured to have gzip, bzip2, lzma, and lzo compression algorithms.
However the Linux kernel supports compressing the Image file using gzip, lzo, lzma, xz, and lz4 compression algorithms, that is, a wider selection of size versus time tradeoffs.
Which one better compression method whether in u-boot or kernel (zImage).
Again, what metric are you going to use to measure "better"?
Of course Wolfgang Denk has his opinion.
Plz explain me with actual example (If any h/w requirement) ... !!!
Example of what?
I've already answered your question, and explained how you can configure your kernel to get the expected message.
The issue was with specifying the compression type "-C" as none.
mkimage -A arm -O linux -T kernel **-C none** -a 0x10000000 -e 0x10000000 -n "Linux kernel" -d arch/arm/boot/zImage uImage
So I tried with vmlinux. and converted it to gzip
mkimage -A arm -O linux -T kernel **-C gzip** -a 0x10008000 -e 0x10008000 -n 'Test' -d vmlinux.bin.gz uImage.
So I have noticed size of both images .
first one is of vmlinux and another of zImage
So please correct me if i am misunderstood .
I'm working on a bsp layer for SBC Pine64 and my image is successfully generated but I'm getting "FATAL: kernel too old" when booting init
from busybox. I've checked my busybox binary and it's being compiled for kernel 3.14.0.
My kernel is version 3.10 and I've used Linaro 5.3 toolchain. I've tried adding: OLDEST_KERNEL = "3.10.0" and I've also tried using Linaro 4.9 but I
still get the same error. I'm using yocto Krogoth and generating core-image-minial. Please, see below a snip of the error from boot log:
[13.068932] EXT4-fs (mmcblk0p2): couldn't mount as ext3 due to feature incompatibilities
[13.086717] EXT4-fs (mmcblk0p2): couldn't mount as ext2 due to feature incompatibilities
[13.112988] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[13.127040] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[13.143393] devtmpfs: mounted
[13.151972] Freeing unused kernel memory: 520K (ffffffc0009e4000 - ffffffc000a66000)
FATAL: kernel too old
[13.198566] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
[13.198566]
[13.218884] CPU: 2 PID: 1 Comm: init Not tainted 3.10.102-pine64 #1
[13.230876] Call trace:
How can I configure yocto to compile linaro eglibc for kernel 3.10.0?
Thx,
Montez
When you want to override an existing variable that is not "soft-assigned", which is to say does not use the ?= syntax but instead = syntax, you need to use one of the variables in OVERRIDES as part of changing the value. You can see how overrides work already as in conf/bitbake.conf we have:
##################################################################
# Kernel info.
##################################################################
OLDEST_KERNEL = "3.2.0"
OLDEST_KERNEL_aarch64 = "3.14"
OLDEST_KERNEL_nios2 = "3.19"
And aarch64 is already found in your overrides list. Fortunately there are other values in that list, and when evaluating variables the ones later in the list in OVERRIDES take precedence. So in your local.conf you can do:
OLDEST_KERNEL_forcevariable = "3.10"
And then confirm that it has taken effect:
$ bitbake -e busybox | grep -E ^OLDEST_KERNEL=
OLDEST_KERNEL="3.10"
I followed tutorial http://www.howtoforge.com/virtualization-with-xen-on-centos-6.2-x86_64-paravirtualization-and-hardware-virtualization
To install xen on Centos 6.3 everything is going perfect but, after editing /boot/grub/menu.lst
Quote:
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/mapper/vg_xen-LogVol01
# initrd /initrd-[generic-]version.img
#boot=/dev/sdb
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.32.57-2.el6xen.x86_64)
root (hd0,0)
kernel /xen.gz dom0_mem=1024M cpufreq=xen dom0_max_vcpus=1 dom0_vcpus_pin
kernel /vmlinuz-2.6.32.57-2.el6xen.x86_64 ro root=/dev/mapper/vg_xen-LogVol01 rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_xen/LogVol01 rd_LVM_LV=vg_xen/lv_swap rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=128M KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet
initrd /initramfs-2.6.32.57-2.el6xen.x86_64.img
title CentOS (2.6.32-279.el6.x86_64)
root (hd0,0)
kernel /vmlinuz-2.6.32-279.el6.x86_64 ro root=/dev/mapper/vg_xen-LogVol01 rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_xen/LogVol01 rd_LVM_LV=vg_xen/lv_swap rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=128M KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet
initrd /initramfs-2.6.32-279.el6.x86_64.img
when i reboot it is booted with xen kernel but when i run command
xm info or xm list
showing error
" Error: Unable to connect to xend: No such file or diectory. Is xend running "
when i run command
xend start
showing error
" xc: error: Could not obtain handle on privileged command interface (2 = No such file or directory): Internal error
xend/image.py: Error connecting to hypervisor "
ls /proc/xen
" ls: cannot access /proc/xen: No such file or directory "
added entry in /etc/fstab
Quote:
none /proc/xen xenfs default 0 0
after reboot gives error no such file or directory,
lsmod | grep -i xen output: Nothing...
modprob xen-evtchn
FATAL: Error inserting xen_evtchn (/lib/modules/2.6.32.57-2.el6xen.x86_64/kernel/drivers/xen/xen-evtchn.ko): No such device
modprob xen-gntdev
FATAL: Error inserting xen_gntdev (/lib/modules/2.6.32.57-2.el6xen.x86_64/kernel/drivers/xen/xen-gntdev.ko): No such device
I have enabled hardware virtulization in bios still problem not solved.
I tried another tutorial https://www.crc.id.au/xen-on-rhel6-scientific-linux-6-centos-6-howto/
it seems like nothing is working for me...
Guys... please share your thoughts about this problem...
Thank you.
i ran into this too in booting a Xen dom0 kernel.
i might have spotted one small omission in your grub.conf compared to the instructions.
in the grub config section at this line: "replace the first word initrd with module."
for example, here's my working Xen Dom0 grub.conf.
good luck!
default=0
timeout=2
title CentOS 6.3 Xen dom0
root (hd0,0)
kernel /boot/xen.gz loglvl=all guest_loglvl=all
module /boot/vmlinuz-dom0-kernel ro root=/dev/sda1 nomodeset console=ttyS0,115200 iommu=off earlyprintk=xen initcall_debug debug loglevel=10
module /boot/initrd-dom0-kernel.img
title CentOS 6.3 (No Xen)
root (hd0,0)
kernel /boot/vmlinuz-dom0-kernel ro root=/dev/sda1
initrd /boot/initrd-dom0-kernel.img
title Stock CentOS 6.3
root (hd0,0)
kernel /boot/vmlinuz-centos6.3 ro root=/dev/sda1
initrd /boot/initrd-centos6.3.img
This does the trick!
Check your boot entries in grub. I just upgraded my Centos 6.3 with the kernel-xen-3.5.3-1 to 3.7.1-3 and the new boot entry for this kernel gets wrong because between updates I installed a standard kernel for testing other things.
Fixing the correct boot options for xen brings back my virtualization!
title CentOS (3.7.1-3.el6xen.x86_64)
root (hd0,0)
kernel /xen.gz dom0_mem=1024M cpufreq=xen dom0_max_vcpus=4 dom0_vcpus_pin
module /vmlinuz-3.7.1-3.el6xen.x86_64 ro root=UUID=<longUUID> KEYBOARDTYPE=pc KEYTABLE=us LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 crashkernel=auto rhgb quiet
module /initramfs-3.7.1-3.el6xen.x86_64.img
I had the same issue:
Could not obtain handle on privileged command interface (2 = No such file or directory): Internal error
This was solved by adding the below line in /etc/fstab
none /proc/xen xenfs defaults 0 0
See this post in the Xen Project mailing list for more details.
I'm compiling a custom kernel under Ubuntu and I'm running into the problem that my kernel doesn't seem to know where to look for firmware. Under Ubuntu 8.04, firmware is tied to kernel version the same way driver modules are. For example, kernel 2.6.24-24-generic stores its kernel modules in:
/lib/modules/2.6.24-24-generic
and its firmware in:
/lib/firmware/2.6.24-24-generic
When I compile the 2.6.24-24-generic Ubuntu kernel according the "Alternate Build Method: The Old-Fashioned Debian Way" I get the appropriate modules directory and all my devices work except those requiring firmware such as my Intel wireless card (ipw2200 module).
The kernel log shows for example that when ipw2200 tries to load the firmware the kernel subsystem controlling the loading of firmware is unable to locate it:
ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection
ipw2200: ipw2200-bss.fw request_firmware failed: Reason -2
errno-base.h defines this as:
#define ENOENT 2 /* No such file or directory */
(The function returning ENOENT puts a minus in front of it.)
I tried creating a symlink in /lib/firmware where my kernel's name pointed to the 2.6.24-24-generic directory, however this resulted in the same error. This firmware is non-GPL, provided by Intel and packed by Ubuntu. I don't believe it has any actual tie to a particular kernel version. cmp shows that the versions in the various directories are identical.
So how does the kernel know where to look for firmware?
Update
I found this solution to the exact problem I'm having, however it no longer works as Ubuntu has eliminated /etc/hotplug.d and no longer stores its firmware in /usr/lib/hotplug/firmware.
Update2
Some more research turned up some more answers. Up until version 92 of udev, the program firmware_helper was the way firmware got loaded. Starting with udev 93 this program was replaced with a script named firmware.sh providing identical functionality as far as I can tell. Both of these hardcode the firmware path to /lib/firmware. Ubuntu still seems to be using the /lib/udev/firmware_helper binary.
The name of the firmware file is passed to firmware_helper in the environment variable $FIRMWARE which is concatenated to the path /lib/firmware and used to load the firmware.
The actual request to load the firmware is made by the driver (ipw2200 in my case) via the system call:
request_firmware(..., "ipw2200-bss.fw", ...);
Now somewhere in between the driver calling request_firmware and firmware_helper looking at the $FIRMWARE environment variable, the kernel package name is getting prepended to the firmware name.
So who's doing it?
From the kernel's perspective, see /usr/src/linux/Documentation/firmware_class/README:
kernel(driver): calls request_firmware(&fw_entry, $FIRMWARE, device)
userspace:
- /sys/class/firmware/xxx/{loading,data} appear.
- hotplug gets called with a firmware identifier in $FIRMWARE
and the usual hotplug environment.
- hotplug: echo 1 > /sys/class/firmware/xxx/loading
kernel: Discard any previous partial load.
userspace:
- hotplug: cat appropriate_firmware_image > \
/sys/class/firmware/xxx/data
kernel: grows a buffer in PAGE_SIZE increments to hold the image as it
comes in.
userspace:
- hotplug: echo 0 > /sys/class/firmware/xxx/loading
kernel: request_firmware() returns and the driver has the firmware
image in fw_entry->{data,size}. If something went wrong
request_firmware() returns non-zero and fw_entry is set to
NULL.
kernel(driver): Driver code calls release_firmware(fw_entry) releasing
the firmware image and any related resource.
The kernel doesn't actually load any firmware at all. It simply informs userspace, "I want a firmware by the name of xxx", and waits for userspace to pipe the firmware image back to the kernel.
Now, on Ubuntu 8.04,
$ grep firmware /etc/udev/rules.d/80-program.rules
# Load firmware on demand
SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware_helper"
so as you've discovered, udev is configured to run firmware_helper when the kernel asks for firmware.
$ apt-get source udev
Reading package lists... Done
Building dependency tree
Reading state information... Done
Need to get 312kB of source archives.
Get:1 http://us.archive.ubuntu.com hardy-security/main udev 117-8ubuntu0.2 (dsc) [716B]
Get:2 http://us.archive.ubuntu.com hardy-security/main udev 117-8ubuntu0.2 (tar) [245kB]
Get:3 http://us.archive.ubuntu.com hardy-security/main udev 117-8ubuntu0.2 (diff) [65.7kB]
Fetched 312kB in 1s (223kB/s)
gpg: Signature made Tue 14 Apr 2009 05:31:34 PM EDT using DSA key ID 17063E6D
gpg: Can't check signature: public key not found
dpkg-source: extracting udev in udev-117
dpkg-source: unpacking udev_117.orig.tar.gz
dpkg-source: applying ./udev_117-8ubuntu0.2.diff.gz
$ cd udev-117/
$ cat debian/patches/80-extras-firmware.patch
If you read the source, you'll find that Ubuntu wrote a firmware_helper which is hard-coded to first look for /lib/modules/$(uname -r)/$FIRMWARE, then /lib/modules/$FIRMWARE, and no other locations. Translating it to sh, it does approximately this:
echo -n 1 > /sys/$DEVPATH/loading
cat /lib/firmware/$(uname -r)/$FIRMWARE > /sys/$DEVPATH/data \
|| cat /lib/firmware/$FIRMWARE > /sys/$DEVPATH/data
if [ $? = 0 ]; then
echo -n 1 > /sys/$DEVPATH/loading
echo -n -1 > /sys/$DEVPATH/loading
fi
which is exactly the format the kernel expects.
To make a long story short: Ubuntu's udev package has customizations that always look in /lib/firmware/$(uname -r) first. This policy is being handled in userspace.
Wow this is very useful information and it led me to the solution for my problem when making a custom USB kernel module for a device requiring firmware.
Basically, every Ubuntu brings a new rehash of hal,sysfs,devfs,udev,and so on...and things just change. In fact I read they stopped using hal.
So let's reverse engineer this yet again so it's pertinent to the latest [Ubuntu] systems.
On Ubuntu Lucid (the latest at time of writing), /lib/udev/rules.d/50-firmware.rules is used. This file calls the binary /lib/udev/firmware, where magic happens.
Listing: /lib/udev/rules.d/50-firmware.rules
# firmware-class requests, copies files into the kernel
SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware --firmware=$env{FIRMWARE} --devpath=$env{DEVPATH}"
The magic should be something along these lines (source: Linux Device Drivers, 3rd Ed., Ch. 14: The Linux Device Model):
echo 1 to loading
copy firmware to data
on failure, echo -1 to loading and halt firmware loading process
echo 0 to loading (signal the kernel)
then, a specific kernel module receives the data and pushes it to the device
If you look at Lucid's source page for udev, in udev-151/extras/firmware/firmware.c, the source for that firmware /lib/udev/firmware binary, that's exactly what goes on.
Excerpt: Lucid source, udev-151/extras/firmware/firmware.c
util_strscpyl(datapath, sizeof(datapath), udev_get_sys_path(udev), devpath, "/data", NULL);
if (!copy_firmware(udev, fwpath, datapath, statbuf.st_size)) {
err(udev, "error sending firmware '%s' to device\n", firmware);
set_loading(udev, loadpath, "-1");
rc = 4;
goto exit;
};
set_loading(udev, loadpath, "0");
Additionally, many devices use an Intel HEX format (textish files containing checksum and other stuff) (wiki it i have no reputation and no ability to link). The kernel program ihex2fw (called from Makefile in kernel_source/lib/firmware on .HEX files) converts these HEX files to an arbitrary-designed binary format that the Linux kernel then picks up with request_ihex_firmware, because they thought reading text files in the kernel was silly (it would slow things down).
On current Linux systems, this is handled via udev and the firmware.agent.
Linux 3.5.7 Gentoo, I have the same issue.
SOLVED:
emerge ipw2200-firmware
Then go to /usr/src/linux
make menucofig
on device driver, remove all wirless drivers don't needed, set Intell 2200 as module and recompile.
make
make modules_install
cp arch/x86/boot/bzImage /boot/kernel-yourdefault