| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Signed-off-by: Rafael Fonseca <rdossant@redhat.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Documentation for OPAL_LPC_READ 67 and
OPAL_LPC_WRITE 68
Signed-off-by: Nageswara R Sastry <rnsastry@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Fixes: fab5418b256817e2695aa653d4840bfa5b5be53b
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In flash_subpart_info, part_actual can't be NULL (we bail out if so),
so this spurious check just manages to trigger warning in static
analysis.
Fixes: 8652ced003f7977e1126149b8011c184b88fe24e
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This patch changes
.txt to .rst for correctness of the documentation files,
path to the documentation files
Signed-off-by: Nageswara R Sastry <rnsastry@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
For this stage in Trusted Boot development, we are wishing to not
force Secure Mode through the whole firmware boot process, but we
are wanting to be able to test it (classic chicken and egg problem with
build infrastructure).
We disabled secure mode if the secure-enabled devtree property is
read from the device tree *IF* we aren't overriding it through NVRAM.
Seeing as we can only increase (not decrease) what we're checking through
the NVRAM variable, it is safe.
The NVRAM setting is force-secure-mode=true in the ibm,skiboot partition.
However, if you want to force secure mode even if Hostboot has *not* set
the secure-enabled proprety in the device tree, set force-secure-mode
to "always".
There is also a force-trusted-mode NVRAM setting to force trusted mode
even if Hostboot has not enabled it int the device tree.
To indicate to Linux that we haven't gone through the whole firmware
process in secure mode, we replace the 'secure-enabled' property with
'partial-secure-enabled', to indicate that only part of the firmware
boot process has gone through secure mode.
Signed-off-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: add NVRAM flag, modify commit message]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
elog_reject_head() routine makes the state 'elog_read_from_fsp_head_state'
either 'ELOG_STATE_REJECTED' or 'ELOG_STATE_NONE' depending on the current
state of 'elog_read_from_fsp_head_state'.
We can remove this elog_reject_head() from 'opal_kexec_elog_notify()' as just
after that it is called inside 'fsp_opal_resend_pending_logs()'. So, it is
redundant inside opal_kexec_elog_notify() routine.
Signed-off-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We use 'elog_enabled' flag to check whether host OS is ready to receive
error log or not. This is nothing to do with reading error log from
service processor.
This patch is to remove the check and keep this 'elog_enabled' free from
FSP specific code and move it into core/errorlog.c in later upcoming patches.
With this changes, in some corner cases we may endup reading same error
log twice from FSP. It happens as we call 'elog_reject_head' inside
'fsp_opal_resend_pending_logs' which makes the state either
'ELOG_STATE_REJECTED' or 'ELOG_STATE_NONE'. So, a call to
'fsp_elog_check_and_fetch_head' routine ends up reading the error
log from FSP which was already read. This case happens twice in a reboot
as whenever 'fsp_opal_resend_pending_logs' gets called.
So, we can ignore it.
Signed-off-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Some modifications related to typo errors, alignment, case letter mismatch to add
more clarity to the code.
Signed-off-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Currently the bootargs are unconditionally deleted, which causes
a bug where the bootargs passed in by the device tree are lost.
This patch deletes bootargs only if it needs to be replaced by the NVRAM
entry.
This patch also removes KERNEL_COMMAND_LINE config option in favour of
using the NVRAM or a device tree.
Signed-off-by: Chris Smart <chris@distroguy.com>
Acked-by: Balbir Singh <bsingharora@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Now that BMC and host kernel mtd drivers exist and have matured we
should use them by default.
This is especially important since we seem to be telling everyone to use
pflash.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Honestly the first name was terrible. Initially this was intended only
to serve for BMC/ARM flash access, however, it should be more generic as
it is in the external/common arch code it should play nice on all
architectures.
This change also paves the way to change the default flash access
methods in pflash.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Acked-by: Joel Stanley <joel@jms.id.au>
[stewart@linux.vnet.ibm.com: preserve Joel's ack]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
If the access method to the flash is PNOR_MTD or BMC_MTD then the
actual access is being done for us by the kernel. This means we don't
need to worry about wrprotecting. The arch level shouldn't be returning
an error, it should be fall though.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Acked-by: Joel Stanley <joel@jms.id.au>
[stewart@linux.vnet.ibm.com: preserve Joel's ack]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Fixes build break on 32bit ppc64 (e.g. PowerMac G5, where user space
is mostly 32bit).
Fixes: https://github.com/open-power/skiboot/issues/42
Reported-by: Andrei Warkenti <andrey.warkentin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Most of the time, if we're rebooting due to a platform error, we should
trigger a checkstop. However, if we haven't been told what we should do
to trigger a checkstop (e.g. on an FSP machine), then we should still
fail to fast-reboot.
So, disable fast-reboot in the OPAL_CEC_REBOOT2 code path
for OPAL_REBOOT_PLATFORM_ERROR reboot type.
We don't save the reason for the platform error as that's already
been error logged.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
[stewart@linux.vnet.ibm.com: unlock before return (suggested by Mahesh/Andrew),
disable only on non-cancelling fsp codeupdate call (suggested by Vasant)]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This fixes the previous reverts of loading the CAPP partition with
STB headers (which broke CAPP partitions without STB headers).
The new logic fixes both CAPP partition loading with STB headers *and*
addresses a long standing bug due to differing interpretations of FFS.
The f_part utility that *constructs* PNOR files just sets actualSize=totalSize
no matter on what the size of the partition is. Prior to this patch,
skiboot would always load actualSize, leading to longer than needed IPL.
The pflash utility updates actualSize, so no developer has really ever
noticed this, apart from maybe an inkling that it's odd that a freshly
baked PNOR from op-build takes ever so slightly longer to boot than one
that has had individual partitions pflashed in.
With this patch, we now compute actualSize. For partitions with a STB
header, we take the payload size from the STB header. For partitions
that don't have a STB header, we compute the size either by parsing
the ELF header or by looking at the subpartition header and computing it.
We now need to read the entire partition for partitions with subpartitions
so that we pass consistent values to be measured as part of Trusted Boot.
As of this patch, the actualSize field in FFS is *not* relied on for
partition size, we determine it from the content of the partition.
However, this patch *will* break loading of partitions that are not ELF
and do not contain subpartitions. Luckily, nothing in-tree makes use of
that.
Fixes: f0a23e4fadcdc49f134e122fa134f183f2e172f7
Based-on-patch-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Add a function to get the software payload size from a STB container.
(originally from patch from Claudio, but I pulled out just this bit here)
Extracted-from-a-patch-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
From the subpartition structure, we have the ability to compute
the full partition size. Do that.
This lets us only read the amount of a subpartition that is valid
and needed to be read, rather than having to read the entire thing.
We continue the current behaviour of loading flash partitions though.
Based-on-patch-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
A unit test for parsing sub-partition info is useful for a number
of reasons, one of which showed its head during development of
secure/trusted boot.
This patch just moves things around, there's no functional changes.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
I made the inappropriate assumption: PCI slot's power state is
always on from the beginning. We don't check the slot's power
state before turning it off in PCI enumeration path when there
are no PCI adapters behind the slot. The PCI slot's power might
have been turned off and we needn't power it off again. Otherwise,
the below (not harmful) message is raised:
[ 47.243635711,5] SkiBoot skiboot-5.4.0-rc1 starting...
:
[ 13.239871630,5] PHB#0001:02:01.0 Error -1 powering off slot
This checks power state and avoid turning it off again if it's
already in off state. Flag PCI_SLOT_FLAG_BOOTUP is also removed
after the requested operation is completed as the flag should
be used at skiboot booting stage.
Cc: stable # 5.3.0+
Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Tested-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
PCI slot pfreset() operation is obsoleted as nobody uses it. This
removes it and the related PCI slot states. No functional changes
introduced.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: Russell Currey <ruscur@russell.cc>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Various backends define their own PCI slot states for flexibility
with numbers [A]. PCI core also defines its PCI slot states [B].
For one specific PCI slot state, the major number of [A] and [B]
should be same so that the corresponding operation can be found.
It means [A] and [B] are relevant to some extent, but the code
where defines the PCI slots in backends doesn't reflect it.
This makes the major PCI slot state defined in backend same to
the corresponding one defined in PCI core. The minor PCI slot
states are made to be incremental to their base number (major
PCI slot state). No functional changes introduced.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
doc/device-tree/tpm.rst
changed firwmare to firmware
libstb/stb.h
added missing functional parameter
Signed-off-by: Nageswara R Sastry <rnsastry@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
If a PHB is in CAPI mode, we cannot safely fast reboot - the PHB will be
fenced during the reboot resulting in major problems when we load the new
kernel.
In order to handle this safely, we need to disable CAPI mode before
resetting PHBs during the fast reboot. However, we don't currently support
this.
In the meantime, when fast rebooting, check if there are any PHBs with a
CAPP attached, and if so, abort the fast reboot and revert to a normal
reboot instead.
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This reverts commit e1e6d009860d0ef60f9daf7a0fbe15f869516bd0.
Breaks DT enough that it makes people cranky, reverting for now
Reported-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This works around a problem introduced with fast-reset where if
we provided initrd through qemu (powernv) command line, we'd delete
the device tree nodes before being able to use them.
Fixes: 0279d8951ead549fdebce93130a2f6c673081862
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This adds a device tree entry which advertises additional support for 2M
and 1G pages in a PAPR compliant manner. Without this, the kernel will
default to only 4K and 64K page sizes.
With this patch, 1G (0x40000000) pages for linear mapping will be used.
This can be seen by when checking the output of "Mapping range" in the
kernel log:
# dmesg |grep "Mapping range"
Mapping range 0x0 - 0x100000000 with 0x40000000
Without this patch, the kernel will use 64K (0x10000) instead:
# dmesg |grep "Mapping range"
Mapping range 0x0 - 0x100000000 with 0x10000
Signed-off-by: Chris Smart <chris@distroguy.com>
Acked-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Warnings in progress.c are not critical but warn about %d being used in printf
format string when the parameter passed is unsigned.
Trivial fixup which should silence the warnings.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
For PCI slot behind root port, its prepare_link_change() should be
same to PHB's. Otherwise, the UTL events cannot be masked when the
slot is reseted, leading to EEH error because of UTL link-down
event.
Cc: stable # 5.3.0+
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This masks surprise link down event on RC or downtream ports
if the PCI slots behind them support PCI surprise hotplug. The
event should be handled by PCI hotplug driver instead of EEH
subsystem.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This claims PCIe surprise hotplug capability through device node's
property "ibm,slot-surprise-pluggable". The slot has the capability
when surprise hotplug is supported in its slot's capability bits or
link state change reporting is supported in PCIe link capability bits.
In order for link state events to be properly raised during surprise
hotplug, the power supply to the slot should be always on. The slot's
power state should be switched accordingly during fundamental reset.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
When RC's downstream link is down, we need reserve spare PCI buses
if it has an associated PCI hotplug slot. Otherwise, the adapter
behind it can't be probed successfully in PCI hot add scenario.
This reserves all available buses (to 255) for RC's hotplug slot
when its downstream is down so that PCI adapter can be hot added
to the slot afterwards.
Cc: stable # 5.3.0+
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We might need know the associated PCI slot before applying the chip
level quirk (phb->ops->device_init()) so that special configuration
on the specific PCI slot can be applied.
This moves the logic of creating PCI slot, applying the quirk and
linking the newly probed device to parent's child list to function
pci_scan_one(). Also, the PCI slot is created prior to applying the
quirk.
Cc: stable # 5.3.0+
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
When OPAL_SUCCESS is returned from slot->ops.set_power_state(),
we need update the PCI toplogy accordingly. This scenario can
happen when builtin power control functionality is ignored to
accomodate PCI surprise hotplug or not supported at all by the
hardware.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We should return cached power state instead of retrieving it from
hardware, meaning we're allowed to have the situation: the power
is off in software, but it's on in hardware when the built-in
power control functionality is ignored for some reasons (e.g.
surprise hotplug support). Otherwise, the adapter behind the
slot won't be probed in PCI hot add path.
This returns the cached power state so that OS sees synchronised
power and PCI slot hotplug state (added/removed).
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We can have PCI slots where the mandatory power functionality isn't
supported. On those PCI slots, we should update (cache) the slot's
power state unconditionally because the power state reflects slot's
hotplug state (added or removed). Without this fix, the power and
slot's hotplug state are mismatched on openPower machines. FSP-based
machines don't have the issue.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This returns error (OPAL_PARAMETER) when having invalid power state
transition requests. The invalid requests include: ON to ON, OFF to
OFF.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
