#
933bee76 |
| 09-May-2023 |
Andrew Geissler <geissonator@yahoo.com> |
systemd: no installation in templated targets
Upstream yocto introduced a change via e510222 (systemd-systemctl: fix instance template WantedBy symlink construction).
This fixes a bug that we in Op
systemd: no installation in templated targets
Upstream yocto introduced a change via e510222 (systemd-systemctl: fix instance template WantedBy symlink construction).
This fixes a bug that we in OpenBMC had been taking advantage of in that we were able to document our templated target dependencies without it actually doing anything. The real installation of services within targets occurs in our bitbake recipes due to the complexity of chassis and host instances on a per machine basis.
Leave the dependency information in the service files but comment them out. It's useful to be able to look at a service and understand which targets it's going to be installed into by the bitbake recipes.
Signed-off-by: Andrew Geissler <geissonator@yahoo.com> Change-Id: I58b4e0f280bcf0268a737aec2613f2d6ca8c8eba
show more ...
|
#
d7469407 |
| 08-Mar-2022 |
Jayanth Othayoth <ojayanth@in.ibm.com> |
PHAL: istep mode: hardware error is not stopping boot process.
In the istep mode an error is logged with hardware error should stop the boot process and stays in Quiesce state if the stop on error
PHAL: istep mode: hardware error is not stopping boot process.
In the istep mode an error is logged with hardware error should stop the boot process and stays in Quiesce state if the stop on error policy is enabled. Noticed diffrent behaviour in istep mode, like Quiesce calls phal-create-boottime-guard-indicator.service. This service starts start_host@0.service, causing normal boot start in the middle of a Quiesce.
In most cases, this would be fine, but we didn't use firmware to boot so we did not run "start_host@0.service".
Proposed fix is to remove Wants=start_host@0.service
Tested: forced the checkstop during istep boot. system stay's at Quiesce state.
Signed-off-by: Jayanth Othayoth <ojayanth@in.ibm.com> Change-Id: I4c11648f9162e2c0c861cb1c96edafd6e22323b6
show more ...
|
#
482a8878 |
| 24-Feb-2022 |
Ramesh Iyyar <rameshi1@in.ibm.com> |
PHAL: Add new service file to indicate guard actions.
- Currently, the host is in the infinite loop to boot if the host firmware trying to recover resources and informs that to the BMC by the gr
PHAL: Add new service file to indicate guard actions.
- Currently, the host is in the infinite loop to boot if the host firmware trying to recover resources and informs that to the BMC by the graceful boot request.
- The PHAL will try to apply guard records in all types of boots.
- The host firmware will try to recover resources if that's are guarded and did not meet the minimum hardware check to boot the host and initiate a graceful boot to adjust boot params (HWAS_STATE).
- When the BMC handles the host graceful boot request, PHAL will apply the guard records and informs self boot engine about the bad resources but, the host firmware did not apply the guard records in the previous boot so when comparing the resources state that's informed by the self boot engine are mismatching and entering into an infinite loop to boot.
- So, the guard records actions changed in the BMC to supports resource recovery feature.
- PowerOn / TI (terminate immediately) / Checkstop / Watchdog timeout:
- Clear ephemeral type records. - Apply persistent type records.
- MPIPL:
- Apply persistent type records of the Core and FC.
- Graceful reboot from hostboot / Reboot from UI user or PHYP:
- No guard actions in the PHAL.
- To support the above guard actions in the BMC for the different boots, BMC will create the "/tmp/phal/boottime_guard_indicator" file by using the added service file that will get triggered as part the obmc-host-start@0.target (PowerOn) and obmc-host-quiesce@0.target (TI, Checkstop, and Watchdog timeout), PHAL need to take appropriate guard actions for the same types of boot and remove that indication so that no guard action can be handled during graceful reboot request from hostboot and Reboot from UI or PHYP as well. MPIPL can be handled by the existing IPL_TYPE value provided by the BMC to PHAL as part of the MPIPL boot request.
- Added the above support in this patch for PHAL.
Tested:
- Pre-request: Created the "MC" of guard records to hit the minimum hardware check.
- Verified by PowerOn (aka cold boot).
- Verified TI and Checkstop by injecting clock error at the runtime. (i2cset -y 8 0x6a 0xb6 0x1a)
- Verified TI and Checkstop by injecting runtime "Fata" guard. (putscom pu.c 20028440 0000000000000800 -n0 -p00 -c1)
- Verified MPIPL by using the PHYP macro. (altermem c00 -t p 00000000)
- Verified Graceful request from hostboot as part boot param adjust and SBE image update request.
- Verified Reboot, GracefulWarmReboot, ForceWarmReboot from the BMC.
Signed-off-by: Ramesh Iyyar <rameshi1@in.ibm.com> Change-Id: I6422a8fb68559d7b02677a2f018f0d726ddd8952
show more ...
|