commit | c21865c469cfc9dffdc15d87710293115cf6d9e4 | [log] [tgz] |
---|---|---|
author | Konstantin Aladyshev <aladyshev22@gmail.com> | Mon Jun 21 14:49:16 2021 +0300 |
committer | Ed Tanous <ed@tanous.net> | Mon Aug 02 15:43:59 2021 +0000 |
tree | f77a6039f79ffc0619c5eaeea2eea7e73af3100a | |
parent | 8b6a35f0f99ed38293f7d134511d6181c88c5a59 [diff] |
Support new boot override setting design Add support for the new boot override setting design that was pushed in the commit: "phosphor-settings-manager: redesign boot setting override feature" (openbmc/openbmc/+/44226). The new design not only simplifies boot override settings handling, but also removes interdependency between BootType/BootSource/ BootMode parameters that was present in the handling code. In the old design there wasn't any place to encode boot override disabled state on a Dbus. Therefore bmcweb used implicit mapping of boot parameters to address the problem of encoding disabled override state: "BootSourceOverrideEnabled=Disabled" = "BootSourceOverrideMode=UEFI" + "BootSourceOverrideTarget=None" But with this approach if you set: "BootSourceOverrideEnabled=Once" "BootSourceOverrideMode=UEFI" "BootSourceOverrideTarget=None" You would later read: "BootSourceOverrideEnabled=Disabled" "BootSourceOverrideMode=UEFI" "BootSourceOverrideTarget=None" Which is not what is expected. Also this interdependency between boot parameters complicates the code. For example if we only try to set the boot mode, we need also to check the boot target and probably set the boot enabled state. If we only try to read boot enabled, we also need to check boot mode and boot target. This is also not good. In the new design there is a specific Dbus interface that is used to store overall override enabled state. With it is possible to remove the implicit mapping of boot parameters to disabled state and remove the unnecessary interdependency between the boot override parameters. Also now with the help of "Support all parameter combinations in Redfish boot tests" (openbmc-test-automation/+/44225) it it possible to test for all combinations of boot override parameters. Tested with the openbmc-test-automation with the aforementioned patch applied (openbmc-test-automation/+/44225) with "boot_type" feature present: robot -v PLATFORM_ARCH_TYPE:x86 \ -v OPENBMC_HOST:<BMC IP> \ redfish/systems/test_boot_devices.robot Also tested with the openbmc-test-automation with the aforementioned patch applied (openbmc-test-automation/+/44225) without "boot_type" feature present: robot -v OPENBMC_HOST:<BMC IP> \ redfish/systems/test_boot_devices.robot More information about boot source override design differences can be found at the mailing list discussions: https://lists.ozlabs.org/pipermail/openbmc/2021-May/026533.html and https://lists.ozlabs.org/pipermail/openbmc/2021-June/026759.html Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com> Change-Id: Id0b24b37a4519a2efbb97da597858c295d7c6c27 Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
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.