Intel WiFi firmware
===================

The driver needs Intel's firmware blob. It is not redistributable, so it is
not included here -- you supply it yourself.

1. Get the file for your card. On a T480 that is normally one of:

     iwlwifi-8265-36.ucode     (Wireless-AC 8265, PCI id 8086:24FD)
     iwlwifi-9000-pu-b0-jf-b0-46.ucode   (Wireless-AC 9560, 8086:9DF0)

   On your Fedora install they live in /lib/firmware/.
   Upstream: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

2. Copy it into this directory, renamed:

     cp /lib/firmware/iwlwifi-8265-36.ucode  payloads/iwlwifi8265.ucode

3. Rebuild the ISO:

     make && ./mkiso.sh

   grub.cfg picks it up automatically as a multiboot module.

4. Boot and watch the serial log (or the WiFi panel) for the bring-up trace:
   PCI id, BAR0, CSR_HW_REV, RF-kill state, APM power-up, firmware sections,
   then whether the ALIVE interrupt arrives.

Hardware coverage
-----------------
WiFi (iwlwifi): 6200/6300, 6205/6235, 7260, 3160, 3165, 3168, 7265,
  8260, 8265, 9260, 9560, AX200, AX201.
  Lenovo E31-70 normally has a 3160 (8086:08B3/08B4) and wants
  iwlwifi-3160-17.ucode -> payloads/iwlwifi3160.ucode

Ethernet: Intel e1000/e1000e, Realtek RTL8139, and the RTL8168/8111/8169
  gigabit family (the NIC in most Lenovo E-series and many desktops).
  The NIC layer probes in that order and uses whichever answers first.

Current status
--------------
Working and verified:
  - PCI detection and chip-family classification
  - BAR0 register window, bus mastering
  - RF-kill detection
  - software reset and APM power-up (MAC clock ready)
  - firmware TLV parsing, checked against the real
    iwlwifi-8265-36.ucode: 4 CPU1 sections, 4 CPU2 sections, 2 paging
    sections, 636520 bytes of microcode -- matching an independent
    analysis of the same file exactly.
    Two off-by-four bugs were fixed here: the header is 88 bytes (not 84)
    and a section carries a 4-byte load address (not 8), which had been
    shifting every section payload.
  - the separator markers 0xFFFFCCCC (CPU1/CPU2) and 0xAAAABBBB (paging)
    are now recognised instead of being written to the device as if they
    were real addresses.

Known gap -- the next milestone:
  Firmware upload currently pokes sections through PRPH registers. The
  8000-family parts (8265) use secure boot and want the sections pushed by
  the FH DMA engine instead, then the CPU released via the secure-boot
  handshake. Until that is written the card will not raise ALIVE, so no
  scanning or association is possible yet.
