Greybus for Zephyr currently configures hardware and peripherals at compile-time The Zephyr Way using DeviceTree.
However, it might be desirable to automatically generate a DT overlay file based on an existing .mnfb (Manifest Binary) file (a .mnfb file is a binary equivalent representation of an .mnfs file and the process is reversible).
That would require some intimate knowledge of the platform and its peripherals, so likely it would need to be done in python, and each supported board would require some file specializing some peripheral mapping.
Ideally, this boils down to making a reversible, extensible, .dts to .mnfs translator. It should probably be added to gbutil.py.
Doing so might be more of a convenience than anything and it should not be a requirement for any milestone. More of an eventual "nice to have".
Also, this does nothing to solve the problem of dynamically configuring peripherals at boot time based on the manifest loaded (from an SD card or EEPROM). Probably the only approach that will work there is to have a "catch all" DT overlay that activates each peripheral that any possible manifest would require. Then at least device instances will not be stripped out of the Zephyr binary.
Greybus for Zephyr currently configures hardware and peripherals at compile-time The Zephyr Way using DeviceTree.
However, it might be desirable to automatically generate a DT overlay file based on an existing
.mnfb(Manifest Binary) file (a.mnfbfile is a binary equivalent representation of an.mnfsfile and the process is reversible).That would require some intimate knowledge of the platform and its peripherals, so likely it would need to be done in python, and each supported board would require some file specializing some peripheral mapping.
Ideally, this boils down to making a reversible, extensible, .dts to .mnfs translator. It should probably be added to gbutil.py.
Doing so might be more of a convenience than anything and it should not be a requirement for any milestone. More of an eventual "nice to have".
Also, this does nothing to solve the problem of dynamically configuring peripherals at boot time based on the manifest loaded (from an SD card or EEPROM). Probably the only approach that will work there is to have a "catch all" DT overlay that activates each peripheral that any possible manifest would require. Then at least device instances will not be stripped out of the Zephyr binary.