Age | Commit message (Collapse) | Author | Files | Lines |
|
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>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
include/chip.h:134:3: warning: symbol 'proc_chip_quirks' was not declared. Should it be static?
In fact it shouldn't be static, it should just exist *once* and that
place is chip.c
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
PNOR partitions downloaded by the resource load framework are not being
measured in habanero, but they should be. The problem is that the
Nuvoton TPM driver is failing to be loaded.
The Nuvoton TPM driver is loaded in stb_init(), but when stb_init() is
called the P8 I2C bus has not been initialized yet. Error message:
"NUVOTON: ibm,opal-id property not found, tpm node parent ..."
This moves stb_init() to later in the boot to meet all its requirements.
Signed-off-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
A bit of a hack to free the flattened device tree on fast reset.
This means we don't leak ~500kb memory every fast reset.
We also count the number of fast resets we've done (if enabled),
which means that for stress testing, we have a hope of finding out
how many we managed to do before we hit a problem.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This is an experimental patch that implements "Fast reboot" on P8
machines.
The basic idea is that when the OS calls OPAL reboot, we gather all
the threads in the system using a combination of patching the reset
vector and soft-resetting them, then cleanup a few bits of hardware
(we do re-probe PCIe for example), and reload & restart the bootloader.
For Trusted Boot, this means we *add* measurements to the TPM, so you
will get *different* PCR values as compared to a full IPL. This makes
sense as if you want to be sure you are running something known then,
well, do a full IPL as soft reset should never be trusted to clear any
malicious code.
This is very experimental and needs a lot of testing and also auditing
code for other bits of HW that might need to be cleaned up.
BenH TODO: I also need to check if we are properly PERST'ing PCI devices.
This is partially based on old code I had to do that on P7. I only
support it on P8 though as there are issues with the PSI interrupts
on P7 that cannot be reliably solved.
Even though this should be considered somewhat experimental, we've had
a lot of success on a variety of machines. Dozens/hundreds of reboots
across Tuleta, Garrison and Habanero.
Currently, we've hidden it behind a NVRAM config option, which *is*
liable to change in the future (to ensure that only those who know
what they're doing enable it)
You can enable the experimental support via nvram option:
nvram -p ibm,skiboot --update-config experimental-fast-reset=feeling-lucky
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[stewart@linux.vnet.ibm.com: hide behind nvram option, include Mambo fixes
from Mikey]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This will be useful for fast reboot which needs to clean a few
things up.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Adds a helper that looks for the given NVRAM config string and checks
that associated value is equal to the supplied value.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The running OS is free to re-write the contents of NVRAM. The skiboot
NVRAM parser relies on the NVRAM contents being valid so we need to
force the NVRAM contents to be revalidated after the host OS has written
to it.
Signed-off-by: Oliver O'Halloran <oohall@gmail.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>
|
|
(cherry picked from 5.3.x commit 762d0082f18e4fb921a2d44a1051b02d8b0f6381)
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In the PCI post-fundamental reset code, a hot reset is performed at the
end. This is causing issues at boot time as a reset signal is being sent
downstream before the links are up, which is causing issues on adapters
behind switches. No errors result in skiboot, but the adapters are not
usable in Linux as a result.
Hot resets also occur in the FSP platform-specific code for conventional
PCI slots, which could cause issues.
This patch fixes some adapters not being configurable in Linux on some
systems. The issue was not present in skiboot 5.2.x.
Cc: stable # 5.3.x
Signed-off-by: Russell Currey <ruscur@russell.cc>
Acked-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Users can set kernel command line boot arguments for Mambo in a tcl
script.
This adds a place holder at the bottom of the skiboot.tcl script so
that users know what format to use.
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>
|
|
int to size_t
Reason of the change as integer value may overflow, and it can give negative
value for the length.
This patch also changes the data type of variable which is compared with
strlen() as the comparison also has to be done on the same level.
Signed-off-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Platforms like mambo doesn't populate 'system-id' DT property. Validate
these properties before using.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com, memset(0) for not found dt props, fix unit test]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We might insert a PCIe switch to PHB direct slot and the downstream
ports of the PCIe switch supports PCI hotplug. This creates dynamic
PCI slots for the downstream ports in the scenario:
* The dynamic PCI slot's label has fixed encoding: "S<domain><bus_num>".
* No associated platform slot.
* The management on dynamic PCI slot relies on the generic layer
implemented in pcie-slot.c.
Requested-by: Li Meng <shlimeng@cn.ibm.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This moves the logic initializing PCI slot to helper function
slot_info_info() so that it can be reused by subsequent patch
supporting dynamic PCI slot creation. No functional changes
introduced.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The ECRC generation and check can't be enabled on Broadcom's NIC
(14e4:168a) when it seats behind PMC PCIe switch downstream port
(11f8:8546). Otherwise, the NIC's config space can not be accessed
and returns 0xFF's on read because of EEH error even after the error
is cleared. The issue is reported from Firestone.
This disables ECRC generation and check on Broadcom's NIC when it
seats behind PMC PCIe switch downstream port. With this applied,
the NIC can be detected successfully.
Reported-by: Li Meng <shlimeng@cn.ibm.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: add description of device workaround is for]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The initial PCIe slot power state should be retrieved from the PCIe
Slot Control register (offset: +0x18), instead of having the fixed
state (power-off) wrongly. Otherwise, we possibly have mismatched
states by software and hardware. One side-effect is PCIe slot can
not be powered off from hardware for the first time.
This fixes above issue by fetching the initial PCIe slot power state
from hardware (PCIe Slot Control register) if the power control is
supported on the slot. Otherwise, it doesn't matter on what we have
for the initial PCIe slot power state.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: use PCI_SLOT_POWER_ON|OFF rather than 1/0]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
It's useful to know the CRS retry times before the PCI device is
detected successfully. In PCI hot add case, it usually indicates
time consumed for the adapter's firmware to be partially ready
(responsive PCI config space).
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
"ibm,slot-label" should not depend on "ibm,slot-location-code". The
later one can not be populted because of oversized "ibm,slot-label"
or PHB's base location code.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Remove the unnecessary space before @pd argument.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
flash_read_corrected() assumes the passed blocklevel device is an
actual flash device. However the blocklevel flash abstraction supports
automatically reading ECC protected data so use that instead.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
[Cyril added true to last param to ffs_init() in flash_register()]
[Cyril rebased onto 46c006f core/console: use char literals instead of
numeric]
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
If NVRAM has ECC (as per the ffs header) then the actual size of the
partition is less than reported by the ffs header in the PNOR then the
actual size of the partition is less than reported by the ffs header.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Currently the policy for calling ECC protecting a range at the
blocklevel layer is that the requested region be completely
unprotected otherwise the call will return an error. It turns out that
duplicate calls to ffs_init() with true as the last parameter (for the
same blocklevel structure) will cause duplicate attempts to
ecc_protect() ranges.
Change the policy within blocklevel to allow duplicate protecting.
In fact the new policy almost guarantees no failure (baring something
odd like malloc() failing). It will detect that the range is currently
already fully protected and do nothing, detect that part of the range
is or is not and extend the existing range or detect that a range fits
perfectly between two ranges in which case it will merge the ranges.
Also adjust tests to match the new policy.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This reverts commit cf39c2a7dd1a2ee9b19a5490f7fa25690b8e8ae3.
Fixes: cf39c2a7dd1a2ee9b19a5490f7fa25690b8e8ae3
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We should use the API properly.
This reverts commit 0657bccb778cbe71fc8c00879826ca0217b7010d.
Fixes: 0657bccb778cbe71fc8c00879826ca0217b7010d
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
If our computed hash of stb container doesn't match what's in the container,
we should abort.
Useful in debug (e.g. in mambo)
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
e.g. in a simulator, we could load in a STB container and verify/measure
it.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
secure/trusted boot
Using some basic math on the ELF headers, we can work out how big the
BOOTKERNEL is that may be already loaded (e.g. in mambo, pointed to in the
device tree or built into the skiboot binary).
From there, we can measure the BOOTKERNEL in the TPM and/or verify signature.
This is only useful in a simulation environment, as real machines will
do all of this throught the load_resource API.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Pass SKIBOOT_ENABLE_MAMBO_STB=1 as environment variable to skiboot.tcl
and the tcl will enable the /ibm,secureboot node, enabling hash and
signature "verification" for that mambo session.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Usually, BMC systems doesn't have too much space for storage.
This removes the lid from the BMC after the lid is flashed.
Signed-off-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This adds the -N option for BMC targets, which does not boot the firmware.
The option helps in situations that we need to flash multiple partitions
before booting the firmware.
Signed-off-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
There are situations where we want to flash a lid that isn't neither
BOOTKERNEL nor PAYLOAD. That's the case for CAPP, to test secure and
trusted boot patches we need to flash CAPP with different secure boot
headers.
This adds the -F option for BMC targets that can be used to flash an
arbitrary lid.
Example: '-F CAPP:cappucode.bin.sec.ecc' will flash CAPP partition with
cappucode.bin.sec.ecc
The eyecatch for each partition is defined in
https://github/open-power/pnor.git
Signed-off-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|