RFC: Add initrd generation to load SSDT tables via ACPI
fe at dev.tdt.de
Fri Jan 13 04:41:26 PST 2023
I have an APU3. This has an I2C bus (SMBUS) to which additional devices
can be connected. On my APU3 board, an IO expander mcp23s08  is
This IO expander provides additional GPIOs. This additional GPIOs are
connected to LEDs. The whole thing worked until kernel version 5.4 of
OpenWrt. But after updating to OpenWrt kernel version 5.10
(openwrt-22.03). I have made the additional LEDs known to the system via
a platform driver, which then integrates these LEDs. The support for
reading out the platform driver data for the driver mcp23s08 has been
removed in the kernel with the commit . I was unable to compile my
platform device driver against kernel 5.10, because of the removed
platform data support of the mcp23s08. I contacted the kernel developer
Andy Shevchenko  who made this change. His suggestion was, that the
data should be made known to the system via an additional SSDT table via
ACPI . Then everything should work like a system that supports
device-tree. I have now played around with SSDT a bit and finally
managed to get the driver responsible again for this device. I had to
create a new SSDT file and compile it with a program from the
acpica-unix package . The file must be moved into an initrd, so this
could be read by the kernel during boot.
Now to my question:
In order to load this new SSDT file, it must be made available to the
kernel via an initrd.
However, initrd handling is currently not supported by OpenWrt.
Manually, it is no problem for me to load the GRUB initrd.
But I would like to have a solution that is generally valid in OpenWrt
during image generation. I have already prepared a pullrequest for
openwrt  on my fork with the changes that are needed. But I am not
sure if this is the right solution.
Additional the acpica-unix package from the package feed  must also
be build for the host, to compile the acpi asl source file into acpi aml
More information about the openwrt-devel