Как Ядро Linux знает, где искать встроенное микропрограммное обеспечение драйвера?
Вы должны использовать изображение, чтобы изменить фактический размер или форму самой пули:
Вы можете использовать фоновое изображение с соответствующими отступами, чтобы подтолкнуть контент, чтобы он не перекрывался:
list-style-image:url(bigger.gif);
или
background-image: url(images/bullet.gif);
3 ответа
С точки зрения ядра см. / 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.
Ядро вообще не загружает прошивку. Он просто сообщает пользовательскому пространству: «Я хочу прошивку с именем xxx » и ожидает, пока пользовательское пространство передаст образ прошивки обратно в ядро.
Теперь в Ubuntu 8.04,
$ grep firmware /etc/udev/rules.d/80-program.rules # Load firmware on demand SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware_helper"
так что как вы обнаружили, udev настроен на запуск firmware_helper , когда ядро запрашивает прошивку.
$ 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
Если вы прочитаете исходный код, вы обнаружите, что Ubuntu написала ] firmware_helper , которое жестко запрограммировано для поиска сначала / lib / modules / $ (uname -r) / $ FIRMWARE , затем / lib / modules / $ FIRMWARE , и никаких других мест. При переводе на sh он делает примерно следующее:
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
это именно тот формат, которого ожидает ядро.
Короче говоря: пакет Ubuntu udev имеет настройки, которые всегда находятся в / lib / firmware / $ (uname -r ) первый. Эта политика обрабатывается в пользовательском пространстве.
В текущих системах Linux это делается с помощью udev и firmware.agent .
Вау, это очень полезная информация, и она привела меня к решению моей проблемы при создании пользовательского модуля ядра USB для устройства, требующего прошивки.
В основном, каждый Ubuntu приносит новое переосмысление hal, sysfs, devfs, udev и так далее... и все только меняется. На самом деле, я читал, что они перестали использовать hal.
Так что давайте еще раз проанализируем это, чтобы это относилось к последним системам [Ubuntu].
В Ubuntu Lucid (последней на момент написания статьи) используется /lib/udev/rules.d/50-firmware.rules. Этот файл вызывает двоичный файл /lib/udev/firmware, где и происходит волшебство.
Листинг: /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}"
Магия должна быть примерно такой (источник: Драйверы устройств Linux, 3-е изд, Ch. 14: The Linux Device Model):
- echo 1 to
loading - копируем прошивку в
data - при неудаче, echo -1 to
loadingи останавливаем процесс загрузки прошивки - echo 0 to
loading(сигнал ядру) - затем, определенный модуль ядра получает данные и выталкивает их на устройство
Если вы посмотрите на исходную страницу Lucid для udev, в udev-151/extras/firmware/firmware. c, исходном тексте бинарного файла прошивки /lib/udev/firmware, именно это и происходит.
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");
Кроме того, многие устройства используют Intel HEX формат (текстовые файлы, содержащие контрольную сумму и другие вещи) (wiki it у меня нет репутации и возможности поставить ссылку). Программа ядра ihex2fw (вызываемая из Makefile в kernel_source/lib/firmware на .HEX файлах) преобразует эти HEX файлы в произвольно разработанный двоичный формат, который ядро Linux затем подхватывает с помощью request_ihex_firmware, потому что они решили, что читать текстовые файлы в ядре глупо (это замедлит работу).