Revision Date Author Comments
# 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 ...