Documentation/driver-api/firmware/fallback-mechanisms.rst

Source file repositories/reference/linux-study-clean/Documentation/driver-api/firmware/fallback-mechanisms.rst

File Facts

System
Linux kernel
Corpus path
Documentation/driver-api/firmware/fallback-mechanisms.rst
Extension
.rst
Size
14818 bytes
Lines
309
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: exported/initcall integration point
Status
integration implementation candidate

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

of start_kernel(), just before calling rest_init(). For normal drivers and
   subsystems using subsys_initcall() to register themselves this does not
   matter. This means that code running earlier cannot use EFI
   embedded-firmware.

2. At the moment the EFI embedded-fw code assumes that firmwares always start at
   an offset which is a multiple of 8 bytes, if this is not true for your case
   send in a patch to fix this.

3. At the moment the EFI embedded-fw code only works on x86 because other archs
   free EFI_BOOT_SERVICES_CODE before the EFI embedded-fw code gets a chance to
   scan it.

4. The current brute-force scanning of EFI_BOOT_SERVICES_CODE is an ad-hoc
   brute-force solution. There has been discussion to use the UEFI Platform
   Initialization (PI) spec's Firmware Volume protocol. This has been rejected
   because the FV Protocol relies on *internal* interfaces of the PI spec, and:
   1. The PI spec does not define peripheral firmware at all
   2. The internal interfaces of the PI spec do not guarantee any backward
   compatibility. Any implementation details in FV may be subject to change,
   and may vary system to system. Supporting the FV Protocol would be
   difficult as it is purposely ambiguous.

Example how to check for and extract embedded firmware
------------------------------------------------------

To check for, for example Silead touchscreen controller embedded firmware,
do the following:

1. Boot the system with efi=debug on the kernel commandline

2. cp /sys/kernel/debug/efi/boot_services_code? to your home dir

3. Open the boot_services_code? files in a hex-editor, search for the
   magic prefix for Silead firmware: F0 00 00 00 02 00 00 00, this gives you
   the beginning address of the firmware inside the boot_services_code? file.

4. The firmware has a specific pattern, it starts with a 8 byte page-address,
   typically F0 00 00 00 02 00 00 00 for the first page followed by 32-bit
   word-address + 32-bit value pairs. With the word-address incrementing 4
   bytes (1 word) for each pair until a page is complete. A complete page is
   followed by a new page-address, followed by more word + value pairs. This
   leads to a very distinct pattern. Scroll down until this pattern stops,
   this gives you the end of the firmware inside the boot_services_code? file.

5. "dd if=boot_services_code? of=firmware bs=1 skip=<begin-addr> count=<len>"
   will extract the firmware for you. Inspect the firmware file in a
   hexeditor to make sure you got the dd parameters correct.

6. Copy it to /lib/firmware under the expected name to test it.

7. If the extracted firmware works, you can use the found info to fill an
   efi_embedded_fw_desc struct to describe it, run "sha256sum firmware"
   to get the sha256sum to put in the sha256 field.

Annotation

Implementation Notes