Author: Ed Tanous (edtanous)
Created: 7-21-25
There are a number of platforms that require handling of state that requires interacting with hardware in a consolidated way. Some examples of this are:
And any number of other cases. Some concrete examples of this kind of init of these things exists here. 1
Very routinely, significant bash scripts are used to do some of this init. Those bash scripts suffer some minor performance penalty on startup, and are generally checked into meta layers, reducing the reuse between platforms.
Initially, a new repository would be created to house the platform-init for gb200nvl platform, and get static analysis autobumps, and recipes reused between platforms.
Platforms will be separated by folder to ensure that platform owners can review and create their platform configurations as required, and identical to the meta-layer process that exists today.
Top level structure will be
platform_init.cpp platform1/init.cpp platform2/init.cpp
Initially a cli argument will be used to compile the appropriate paths for a given platform. At some point in the future, some level of detection may be added that allows detecting platforms at runtime. Design for that is to be determined based on future requirements.
Guard rails will need to evolve over time, but initially this repository will not interact with DBus or the OpenBMC model. As defined (at this time) it is purely for initial bringup of hardware.
Status quo, continue building init scripts in bash. This leads to a lack of code reuse, and while some layers have done an excellent job keeping the code clean, it's still very difficult to refactor/consolidate.
Testing section omitted. Platform boot will be tested using individual platforms, with no change.