commit | 567e3ab77c0770da7def4352808e2744aa13369e | [log] [tgz] |
---|---|---|
author | Chalapathi Venkataramashetty <chalapathix.venkataramashetty@intel.com> | Mon May 17 04:42:57 2021 +0000 |
committer | Ed Tanous <ed@tanous.net> | Thu Sep 30 15:35:09 2021 +0000 |
tree | 860f920447274819490953ebe571e657b1447c85 | |
parent | 68452cb09d5b9b87df48217750d4ad7eb387aedc [diff] |
Add message registry entry for FirmwareResiliencyError Add an event log in redfish when firmware update failed due to FirmwareResiliencyError. The existing message entries BMCFirmwareResiliencyError(for BMC update failures) and BIOSFirmwareResiliencyError(for BIOS update failures) are not useful for the new platform. The new platform's CPLD report common error code for BMC, PCH or CPLD firmware update failures. Hence a common message entry is required to capture the firmware update failure events. This event is Implemented in the following review. https://gerrit.openbmc-project.xyz/c/openbmc/pfr-manager/+/43281 Tested: Redfish Service Validator passed for this change. Update BMC firmware with mismatched SVN POST: https://<BMC_IP>/redfish/v1/UpdateService/ with <BMC_Update_Capsule> binary file After BMC reboots check for Event log in Redfish Command: GET: https://<BMC_IP>/redfish/v1/Systems/system/LogServices/ EventLog/Entries Response: { "@odata.id": "/redfish/v1/Systems/system/LogServices/ EventLog/Entries/1621435142_1", "@odata.type": "#LogEntry.v1_4_0.LogEntry", "Created": "2021-05-19T14:39:02+00:00", "EntryType": "Event", "Id": "1621435142_1", "Message": "Firmware resiliency error. Error reason: Firmware update failed(MinorCode:0x02).", "MessageArgs": [ "Firmware update failed(MinorCode:0x02)" ], "MessageId": "OpenBMC.0.1.FirmwareResiliencyError", "Name": "System Event Log Entry", "Severity": "Critical" }, Signed-off-by: Chalapathi Venkataramashetty <chalapathix.venkataramashetty@intel.com> Change-Id: Id13a29ecc160b8e9e1c0b926f6caf882fa746567
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.