| commit | 0ef217f4e89016e8f49f487fe65934b934aab077 | [log] [tgz] |
|---|---|---|
| author | George Liu <liuxiwei@inspur.com> | Mon Mar 08 14:24:46 2021 +0800 |
| committer | George Liu <liuxiwei@inspur.com> | Wed Jun 30 00:41:19 2021 +0000 |
| tree | bb41a5838093cb6bd8b8e9e5c86a094617d1702b | |
| parent | 0e8ac5e706c531d2a3e2fc8390d9a31b90a91eb1 [diff] |
log_services: Add AdditionalDataURI to Post Code log entries - Need to support the Additional Data URI on Post Code log service. IBM progress codes are typically 72 bytes including a primary code (8 bytes) and a secondary code that contains hex words that would provide additional details on the core problem during boot hangs. These secondary hex words would be in this Additional Data URI. - Need to check for the secondary progress code(std::vector<uint8_t>) If it is empty, then do not generate the Additional Data URI. If it is not empty, then generate Additional Data URI for that particular post entry. - This commit is not alone for IBM, it is a generic code that should work on every system. As per the recent PDI change that went into Progress code structure https://github.com/openbmc/phosphor-dbus-interfaces/commit/9a96970ebb93eb1f495c200801343a4d1c53977c#diff-0aad0ef8ed32e2652256f50357eede1aedd6ff1398df1bb1a121ad9125916c5f 1. The primary code(uint64_t) is what we see in the BIOSPOSTCode Message registry. 2. The secondary code(array[byte]) is the entire raw buffer which could be used to offload the information out of BMC. This should not impact any systems that does not have a secondary code, as if the secondary code is empty -> we will not populate the AdditionalDataURI at all. Tested: - Ran Redfish validator which instructed to bump the odata.type from v1_4_0 to v1_8_0 and passed. - Verified the new AdditionalDataURI was correct for LogServices/PostCodes/Entries/<str>: $ curl -k https://127.0.0.1:2443/redfish/v1/Systems/system/LogServices/PostCodes/Entries/B1-1 { "@odata.id": "/redfish/v1/Systems/system/LogServices/PostCodes/Entries", "@odata.type": "#LogEntry.v1_8_0.LogEntry", "Description": "Collection of POST Code Log Entries", "Members": [ { "@odata.id": "/redfish/v1/Systems/system/LogServices/PostCodes/Entries/B1-1", "@odata.type": "#LogEntry.v1_8_0.LogEntry", "AdditionalDataURI": "/redfish/v1/Systems/system/LogServices/PostCodes/Entries/B1-1/attachment", ... ... } ], "Members@odata.count": 1, "Name": "BIOS POST Code Log Entries" } Signed-off-by: George Liu <liuxiwei@inspur.com> Change-Id: I897888a08db94e22b5a8098bc2a874b00bfb5361
This component attempts to be a "do everything" embedded webserver for openbmc.
At this time, the webserver implements a few interfaces:
BMCWeb is configured by setting -D flags that correspond to options in bmcweb/meson_options.txt and then compiling. For example, meson <builddir> -Dkvm=disabled ... followed by ninja in build directory. The option names become C++ preprocessor symbols that control which code is compiled into the program.
meson builddir ninja -C builddir
meson builddir -Dbuildtype=minsize -Db_lto=true -Dtests=disabled ninja -C buildir
If any of the dependencies are not found on the host system during configuration, meson automatically gets them via its wrap dependencies mentioned in bmcweb/subprojects.
meson builddir -Dwrap_mode=nofallback ninja -C builddir
meson builddir -Dbuildtype=debug ninja -C builddir
meson builddir -Db_coverage=true -Dtests=enabled ninja coverage -C builddir test
When BMCWeb starts running, it reads persistent configuration data (such as UUID and session data) from a local file. If this is not usable, it generates a new configuration.
When BMCWeb SSL support is enabled and a usable certificate is not found, it will generate a self-sign a certificate before launching the server. The keys are generated by the secp384r1 algorithm. The certificate
C=US, O=OpenBMC, CN=testhost,SHA-256 algorithm.