Our M.2 key B slot can support different modules, some of which require switching hardware interfaces and pin configs: e.g. disable PCIe and enable SATA, or mux audio onto two or four pins in the slot, depending on what the module wants.
These configurations are requested by the strapping of CONFIG1..4 pins on the card (high or low level). We need to add infrastructure in U-boot (and/or U-boot SPL) to patch the device tree with the required information based on the values of config pins before it passes the device tree to Linux.
This will likely require a new DT binding for M.2 key B cards and some sort of DT graph or phandle based linkage of individual interface providers (such as the SATA controller) to the M.2 connector node.
Our M.2 key B slot can support different modules, some of which require switching hardware interfaces and pin configs: e.g. disable PCIe and enable SATA, or mux audio onto two or four pins in the slot, depending on what the module wants.
These configurations are requested by the strapping of CONFIG1..4 pins on the card (high or low level). We need to add infrastructure in U-boot (and/or U-boot SPL) to patch the device tree with the required information based on the values of config pins before it passes the device tree to Linux.
This will likely require a new DT binding for M.2 key B cards and some sort of DT graph or phandle based linkage of individual interface providers (such as the SATA controller) to the M.2 connector node.