(old)Puppy Linux Discussion Forum

Edit:
My firmware file repository is about to disappear.
Please use this alternate site, http://anduin.linuxfromscratch.org/BLFS/linux-firmware,
to acces the files from http://git.kernel.org/cgit/linux/kernel ... rmware.git.

The firmware sfs files have now moved to
http://www.mediafire.com/folder/k2j223jzddy9x/firmware (150MB).
Simply download and use as an adrv, ydrv or fdrv.

I no longer download this firmware repository, http://git.kernel.org/cgit/linux/kernel ... rmware.git,
and I no longer install it here, http://www.fishprogs.software/puppy/firmware/.

Some folk using modern kernels are having problems with some hardware, because the required firmware is not in puppy.
There are 2 reasons for this:
1) The commonly used firmware '.tar.bz2' files are now almost 6 months old.
2) The commonly used 'cut' version does not contain a significant number of firmware files.

Note1: This directory of firmware corresponds to the "/lib/firmware/" directory in puppy.

Note2: It's not pretty, because it's just the web-server generating an index of the directory.

Question: Why is the firmware distributed as part of the kernel?
It's not produced by compiling the kernel. It's just copied from one of the '.tar.bz2' files.

gyro

Edit: Should have included information about how I expect folk might use this repository in an ad-hoc manner. So here is an example of using it on an ether-net device.

1) I found I had a problem when I got some output from the console command:2) If you are lucky, the output from "dmesg" will also tell you the name of the firmware that failed to load.
In my case it didn't so I had to make a guess based on it being identified as an "RTL8168g".
3) Open the repository in a browser and find the required firmware file and download it. In my case I found 3 likely files in 'rtl_nic/'; 'rtl8168g-1.fw', 'rtl8168g-2.fw' and 'rtl8168g-3.fw', so I downloaded all 3.
4) Copy the downloaded firmware file to '/lib/firmware', making sure that you put it in any corresponding sub-directory. Since the file I was trying 'rtl8168g-3.fw' was contained in the 'rtl_nic' subdirectory of the repository, I copied it to '/lib/firmware/rtl_nic/rtl8168g-3.fw'.
5) Reboot and see if "dmesg" is now clean. In my case it wasn't so I tried again with 'rtl8168g-2.fw'. And that worked.

mirror mirrored here:

http://archive.org/details/Puppy_linux_ ... repository

@ally
Thanks.
gyro

Noob question : My /lib/firmware folder is around 2.5MB, that complete set as presented by gyro is around 80MB. If I merge/replace my existing /lib/firmware with that more complete set and then remaster is that all that is required for the newly remastered version to be able to better placed to boot/work across a wider range of hardware/devices? Or is firmware only part of it and something else has to accompany the firmware?

TIA

First post has been edited to include an example of how I envisioned the repository might be used.
gyro

rufwoof wrote:Noob question : My /lib/firmware folder is around 2.5MB, that complete set as presented by gyro is around 80MB. If I merge/replace my existing /lib/firmware with that more complete set and then remaster is that all that is required for the newly remastered version to be able to better placed to boot/work across a wider range of hardware/devices?

Yes, you could do that, and I have considered making an sfs file for such a purpose. But I envisioned a more ad-hock usage when I uploaded the firmware. See the edit of the first post.

rufwoof wrote:Or is firmware only part of it and something else has to accompany the firmware?

Firmware runs in the device, and is therefore not actually part of the kernel. But newer drivers, which are part of the kernel, may expect newer firmware to be available. So devices that worked perfectly in an older kernel, can sometimes have firmware problems with a newer kernel.

gyro

Thanks.

I've dropped (merged) it all into lib/firmware and remastered using lzop level 1 compression rather than leaving puppy sfs uncompressed and rebooted that puppy and it now uses less memory but has all 80MB of firmware available to it rather than the 2.5MB of firmware previously to hand.

Yes I know - wasteful of memory, but with GB's common nowadays 80MB odd isn't missed IMO.

Thanks again.

The github repository has been updated with a new version of "rtlwifi/rtl8192eefw.bin".
I have uploaded the new version of "rtlwifi/rtl8192eefw.bin" to my site.

gyro

Uploaded updated Marvell firmware, replaced all files in "mrvl/".
gyro

Update "/intel/*" and "iwlwifi-*-12.ucode" firmware.
gyro

Updated files:

cbfw-3.2.5.1.bin
ct2fw-3.2.5.1.bin
ctfw-3.2.5.1.bin
iwlwifi-3160-10.ucode
iwlwifi-7260-10.ucode
iwlwifi-7265-10.ucode
iwlwifi-7265D-10.ucode
qat_895xcc.bin

gyro

In directory "rtl_nic" updated files:
rtl8107e-1.fw
rtl8107e-2.fw
rtl8168h-1.fw
rtl8168h-2.fw

gyro

nvidia/tegra124/xusb.bin
htc_7010.fw
htc_9271.fw

gyro

iwlwifi-3160-10.ucode
iwlwifi-7260-10.ucode
iwlwifi-7265-10.ucode
iwlwifi-7265D-10.ucode

gyro

In directory 'radeon', updated files:
kaveri_mec2.bin
kaveri_mec.bin

gyro

Thank you for this excellent initiative and comprehensive collection.

I have not seen this in any other distro, so probably there is a good reason for that (...), but I was wondering if a utility could be build that may scavenge logs (kernel, udev, Xorg) to determine where the problem might be and then offer to get/update the firmware from your site.
I'm assuming should be some user input about the failing device or at least the category, to help narrow down the search and utilise the correct utility call to detect hardware. UI if any, should be terminal-based and thus fairly simple.

Do you think that such a thing might worth the effort?

mavrothal wrote:Thank you for this excellent initiative and comprehensive collection.

Thanks, you're welcome.

mavrothal wrote:Do you think that such a thing might worth the effort?

It would be really nice, but I'm not sure it's worth it.
Challange:
How to identify the required firmware file with a program?
On one occasion I have seen 'dmesg' contain an error message about missing firmware that identified the firmware file it was trying to load.
On another occasion the 'dmesg' error message only said that it failed to load a firmware file, no clue given as to which file.
Unfortunately, I think this error is reported by the driver, so the error message can be different for each driver.

gyro

@mavrothal,
Actually keeping the repository updated is not a lot of fun.
What would be nice is a script to extract a specified file, or all files for a specified driver, directly from the git-hub. Thus making my repository obsolete.

Any ideas?

Creating a local clone of their repository and then extracting the few required files from this, is easily doable, but extremely network expensive.

Edit: I've started on a script to automate, as much as possible, the updating of my repository.

gyro

htc_7010.fw
htc_9271.fw

In directory ath9k_htc:
htc_7010-1.4.0.fw
htc_9271-1.4.0.fw

In directory ath10k/QCA988X/hw2.0:
firmware-4.bin

In directory brcm:
brcmfmac43242a.bin
brcmfmac43340-sdio.bin
brcmfmac4339-sdio.bin
brcmfmac43455-sdio.bin
brcmfmac4354-sdio.bin
brcmfmac4356-pcie.bin
brcmfmac43602-pcie.ap.bin
brcmfmac43602-pcie.bin

gyro

gyro wrote:@mavrothal,
Actually keeping the repository updated is not a lot of fun.
What would be nice is a script to extract a specified file, or all files for a specified driver, directly from the git-hub. Thus making my repository obsolete.

Any ideas?

What about if you clone the repo locally and then periodically do to get all the new/changed files and then use the resulting paths to move them to your repo.
You can do more fancy things using the git log and checking for specific things. As far as I can see the commit messages are pretty straight forward so you can check for "add" "update" "upgrade" and only get files then.