| Message ID | 20211226153624.162281-1-marcan@marcan.st |
|---|---|
| Headers | show |
| Series | brcmfmac: Support Apple T2 and M1 platforms | expand |
On Mon, Dec 27, 2021 at 12:36:05AM +0900, Hector Martin wrote: > The Wi-Fi module in Apple machines has a "module-instance" device > property that specifies the platform type and is used for firmware > selection. Its value is a string, so add support for string values in > acpi_extract_apple_properties(). > > Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Lukas Wunner <lukas@wunner.de>
Hi, On 12/26/21 20:17, Lukas Wunner wrote: > On Mon, Dec 27, 2021 at 12:35:50AM +0900, Hector Martin wrote: >> # On firmware >> >> As you might expect, the firmware for these machines is not available >> under a redistributable license; however, every owner of one of these >> machines *is* implicitly licensed to posess the firmware, and the OS >> packages containing it are available under well-known URLs on Apple's >> CDN with no authentication. > > Apple's EFI firmware contains a full-fledged network stack for > downloading macOS images from osrecovery.apple.com. I suspect > that it also contains wifi firmware. > > You may want to check if it's passed to the OS as an EFI property. > Using that would sidestep license issues. There's EDID data, > Thunderbolt DROM data and whatnot in those properties, so I > wouldn't be surprised if it contained wifi stuff as well. > > Enable CONFIG_APPLE_PROPERTIES and pass "dump_apple_properties" > on the command line to see all EFI properties in dmesg. > Alternatively, check "ioreg -l" on macOS. Generally, what's > available in the I/O registry should also be available on Linux > either as an ACPI or EFI property. Interesting, note that even if the files are not available as a property we also have CONFIG_EFI_EMBEDDED_FIRMWARE, see: drivers/firmware/efi/embedded-firmware.c Documentation/driver-api/firmware/fallback-mechanisms.rst I wrote this to pry/dig out some touchscreen firmwares (where we have been unable to get permission to redistribute) out of EFI boot_services_code mem regions on tablets where the touchsceen is supported under the EFI environment. This may need some tweaks, but if there is an embedded copy of the firmware files in the EFI mem regions somewhere it should be possible to adjust this code to grab it and present it to the firmware-loader mechanism as a fallback option. Refards, Hans
On 2021/12/27 6:42, Hans de Goede wrote: > Hi, > > On 12/26/21 20:17, Lukas Wunner wrote: >> On Mon, Dec 27, 2021 at 12:35:50AM +0900, Hector Martin wrote: >>> # On firmware >>> >>> As you might expect, the firmware for these machines is not available >>> under a redistributable license; however, every owner of one of these >>> machines *is* implicitly licensed to posess the firmware, and the OS >>> packages containing it are available under well-known URLs on Apple's >>> CDN with no authentication. >> >> Apple's EFI firmware contains a full-fledged network stack for >> downloading macOS images from osrecovery.apple.com. I suspect >> that it also contains wifi firmware. >> >> You may want to check if it's passed to the OS as an EFI property. >> Using that would sidestep license issues. There's EDID data, >> Thunderbolt DROM data and whatnot in those properties, so I >> wouldn't be surprised if it contained wifi stuff as well. >> >> Enable CONFIG_APPLE_PROPERTIES and pass "dump_apple_properties" >> on the command line to see all EFI properties in dmesg. >> Alternatively, check "ioreg -l" on macOS. Generally, what's >> available in the I/O registry should also be available on Linux >> either as an ACPI or EFI property. > > Interesting, note that even if the files are not available as > a property we also have CONFIG_EFI_EMBEDDED_FIRMWARE, see: > > drivers/firmware/efi/embedded-firmware.c > Documentation/driver-api/firmware/fallback-mechanisms.rst > > I wrote this to pry/dig out some touchscreen firmwares (where > we have been unable to get permission to redistribute) out of > EFI boot_services_code mem regions on tablets where > the touchsceen is supported under the EFI environment. > > This may need some tweaks, but if there is an embedded copy > of the firmware files in the EFI mem regions somewhere it > should be possible to adjust this code to grab it and present > it to the firmware-loader mechanism as a fallback option. Note that this wouldn't work on M1 Macs anyway, since those don't have EFI (we provide EFI via U-Boot as a chained bootloader on those), and their bootloader doesn't support any networking (it doesn't even do USB or any kind of UI). Quick recap for those not familiar with the M1 boot process: the bootloader is iBoot, which is extremely simple (at least compared to EFI). All it can do is boot kernels from APFS volumes on internal NVMe. The boot selection menu and recovery options are implemented as macOS apps running from a recovery image (~1GB), and "USB boot" is implemented by copying the macOS equivalent of /boot to NVMe. There is a global recovery image as well as per-OS recovery image. The WiFi firmware is present in this image as well as on normal macOS root volumes. Our Linux install script is actually mostly a macOS install script that sets up all the boot components that macOS would normally have, including the recovery image, minus the main root filesystem. This is all required to work properly within Apple's security and multi-boot framework. So, since we're installing the recovery image, we're already in an easy position to pull the firmware out and stick it in the EFI partition for Linux to easily use. The alternative would be for Linux userspace to read it from APFS directly, but that seems unlikely to be practical until linux-apfs is upstreamed. For T2 Macs I'm sure the firmware will be in EFI somewhere, but even if we can get it from there (I wouldn't be surprised if it's e.g. still compressed in the normal boot path that doesn't start network services), I'm not sure it's worth implementing yet another mechanism for those machines. Once we have the vendor-firmware mechanism implemented for M1, it's easy to just run the same script on T2s and get the proper firmware from macOS (which might even be different from the EFI firmware...). macOS definitely doesn't read the firmware from EFI on those machines, so a hack to do it by scanning the code would probably not be something we can rely on to continue working across firmware updates (and they do update WiFi firmware; it's a rather well known source of security issues... so then we'd have to play the update-the-sha256 cat and mouse game). I'm pretty sure there's no property containing the big firmware blob passed explicitly to the OS; it has its own copy.