Tiny Core Extensions > TCE Tips & Tricks

How to fix failed firmware loading in TC16

<< < (2/4) > >>

Juanito:
If things work in tc-15.x and not in tc-16.x either something changed, there’s a kernel bug or the hardware driver has the firmware path hardcoded.

nick65go:

--- Quote from: GNUser on June 02, 2025, 12:13:02 PM ---Another option is to put the firmware in its own initramfs. This approach makes it obvious to you how your setup is different from vanilla TCL, which is helpful to remember when upgrading. It's also convenient because you don't have to remaster  core.gz  every time you upgrade.

--- End quote ---
Right, better. but with one little remark: the firmware.gz should have only the necessary blobs. I mean to avoid loading in RAM something like 16MB instead of just few KB of few files g-zipped. The  necessary files can be discovered from dmesg kernel log.
For the hard-coded path into firmware, someone can see "interesting things" with a hex viewer/editor, or strings, if modinfo is clueless.

[rant] We are captive to greedy IP -- intellectual property bullshit, close source firmware in software, in hardware UEFI, etc. So no security is possible in this environment. Like: you can not safety build your house on other people land... Maybe we just naively bet on attacker lack of resources/hardware/technology, or lack of knowledge, or security by obscurity (0 days bugs). [/rant]

GNUser:

--- Quote from: nick65go link=topic=27668.msg178910#msg178910 ---  only the necessary blobs.

--- End quote ---
Of course.

I run TCL on several different machines. I found it simpler to create a single firmware initramfs that contains all the blobs I need on all my various devices. Even so, my  firmware.gz  is only 1.1 MB. To me, the slight bloat is worth the simplicity of having the same  firmware.gz  on all my devices. I also have a tiny text file in there with my notes on the purpose of each blob.

CNK:

--- Quote from: Juanito on June 03, 2025, 04:15:54 AM ---If things work in tc-15.x and not in tc-16.x either something changed, there’s a kernel bug or the hardware driver has the firmware path hardcoded.

--- End quote ---

If you want the specifics, it seems that there's an old and new way to do firmware loading. The old way was using udev, which appears to call the script "/lib/udev/firmware.sh", where in TC the "/usr/local/lib/firmware" path is specified. The new way is for the kernel to do it without udev using the code I pointed to before.

Apparantly this all started with a big argument in 2012, leading to this solution:

--- Quote ---An alternative is to simply short out udev for firmware loading altogether. That is, in fact, what has been done; the 3.7 kernel will include a patch (from Linus) that causes firmware loading to be done directly from the kernel without involving user space at all. If the kernel is unable to find the firmware file in the expected places (under /lib/firmware and variants) it will fall back to sending a request to udev in the usual manner. But if the kernel-space load attempt works, then udev will never even know that the firmware request was made.

--- End quote ---

"CONFIG_FW_LOADER_USER_HELPER=y" and "CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y" in TC16's kernel configuration enables the fall-back method.

Either udev is failing during the fall-back method (an issue like what prompted the change), or someone's changed the kernel's Radeon GPU driver code to not call udev anymore (in drivers this can be done by calling request_firmware_direct() instead of request_firmware()). The kernel documentation for the uevent fall-back firmware loader says support for it was removed from Systemd udev in 2014, so it might easily be overlooked. The udev fall-back code is still there in the kernel though.

Rich:
Hi CNK

--- Quote from: CNK on June 03, 2025, 07:06:18 PM --- ... If you want the specifics, it seems that there's an old and new way to do firmware loading. The old way was using udev, which appears to call the script "/lib/udev/firmware.sh", where in TC the "/usr/local/lib/firmware" path is specified. ...
--- End quote ---
I think that method may have been broken for some time:

--- Code: ---tc@E310:~$ cat /etc/udev/rules.d/50-firmware.rules
# do not edit this file, it will be overwritten on update

# firmware-class requests, copies files into the kernel
#SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware --firmware=$env{FIRMWARE} --devpath=$env{DEVPATH}"
SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware.sh"
tc@E310:~$
--- End code ---
There is no path included with "firmware.sh", so I don't think
it will be found.

Navigation

[0] Message Index

[#] Next page

[*] Previous page