Age | Commit message (Collapse) | Author | Files | Lines |
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
While we'll 'never' have flash chips larger than 32bit, work was
recently done to blocklevel for it to be 64bit compatible for other
backends.
Since there is a 64bit ioctl() lets use it. There is currently no known
case where 32bit is not sufficient but this doesn't mean someone might
not do something strange in the future.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Just blocklevel_erase() from zero to sizeof.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Currently the arch flash code for all architectures can only perform
chip erases if there is a real flash driver attached.
With increasing use of MTD on both host and BMC this code needs to know
how to behave of the backend of blocklevel is MTD.
This patch teaches the ARM specific code to pass an erase for the full
size of the chip down the stack. This can be optimised into a chip erase
within the kernel.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Fixes: 5611389876a748e19b7593d4eb426ced7a6ed31f
Reported-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Because Fedora repositories are unreliable and we often get:
Error: Failed to synchronize cache for repo 'updates'
:(
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
An out of tree platform (p8dtu) uses a different IPMI OEM command
for IPMI_PARTIAL_ADD_ESEL. This exposed some assumptions about the BMC
implementation in our core code.
Now, with platform.bmc, each platform can dictate (or detect) the BMC
that is present. We allow it to be set at runtime rather than purely
statically in struct platform as it's possible to have differing BMC
implementations on the one machine (e.g. AMI BMC or OpenBMC).
Acked-by: Jeremy Kerr <jk@ozlabs.org>
[stewart@linux.vnet.ibm.com: remove enum, update (C) years]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Currently Hostboot populates /bmc/sensors dt node and corresponding sensors
only for BMC platforms, And for FSP platforms hostboot is not populating any
fsp sensors(Management sensors) and also there is no firmware progress sensor
exist in fsp platforms. Due to which OPAL incorrectly setting firmware status
on a sensor id "00" which is not at all exist.
On a FSP system:
cat /sys/firmware/opal/msglog | grep -i setting
[ 21.189204883,6] IPMI: setting fw progress sensor 00 to 07
[ 21.189559121,6] IPMI: setting fw progress sensor 00 to 13
cat /sys/firmware/opal/msglog | grep -i skiboot
[ 84.127416495,5] SkiBoot skiboot-5.4.0-rc3 starting...
On a BMC system:
cat /sys/firmware/opal/msglog | grep -i setting
[ 3.166286901,6] IPMI: setting fw progress sensor 05 to 14
[ 14.259153338,6] IPMI: setting fw progress sensor 05 to 07
[ 14.469070593,5] IPMI: Resetting boot count on successful boot
[ 15.001210324,6] IPMI: setting fw progress sensor 05 to 13
So this patch fixes this incorrect setting on a fsp system, and also sets the sensor
only if OPAL initialises ipmi sensors and corresponding sensor exists for a given
sensor type in the device tree.
After patch:
On a FSP system:
cat /sys/firmware/opal/msglog | grep -i setting
On a BMC system:
cat /sys/firmware/opal/msglog | grep -i setting
[ 3.164859816,6] IPMI: setting fw progress sensor 05 to 14
[ 14.024941077,6] IPMI: setting fw progress sensor 05 to 07
[ 14.211514767,5] IPMI: Resetting boot count on successful boot
[ 14.252554375,6] IPMI: setting fw progress sensor 05 to 13
Signed-off-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: return OPAL_UNSUPPORTED on !sensors_present,
make ipmi_sensor_type_present() static in ipmi-sensor.c]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Fixes: 86640b032d79ff0 (pflash: Fix printf format warning)
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The criteria to match the filter according to PCI config register
offset and length is strict one, meaning the accessed region should
matches with the filter's tracking region. However, the code isn't
correct enough - @len should be replaced with @pcrf->len.
The strict matching has to account for the length of current PCI
config register access. We have to specify precise region through
@start and @len in pci_virt_add_filter() when creating the filter.
We lost flexibility. This changes the strict criteria to a relaxed
one - the matched filter is returned when the accessed region is
overlapped with the filter's region. With this change, the individual
filter's handlers should validate the accessed (register) region if
necessary.
Fixes: 85daa7f00c50 ("core/pci: Support virtual device")
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Reviewed-by: Alistair Popple <alistair@popple.id.au>
Acked-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Fixes: 879caa27dd19873510f9ea58cdefb4775197abd2
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>
|
|
Currently we warn the user and truncate the file by default. Instead
abort as this is rarely the desired behaviour.
You can still shoot yourself in the foot by passing --force.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
No functional change
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Also moves some code around to ensure things are defined before they
are used.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Also changes the function name:
mambo_read/write() -> mambo_console_read/write()
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
To be used for rtc and simstop calls
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Make callthru functions return 64 bits so we can return larger
numbers.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
These OPAL calls are exposing the host flash chip to linux as a flash
device. The host is expected to understand that it is raw flash and use
it appropriately, it isn't skiboots place to strip ecc bytes or perform
erase before writes.
Over the course of other developments blocklevel has gotten quite clever
but in this case the cleverness is inappropriate.
Fixes: https://github.com/open-power/skiboot/issues/44
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Because IPMI raw commands copied out of internal bugzilla is the best
source of things that need to go in test scripts.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In the fast reboot path opal sends multiple special sequence to all the
CPUs using xscom operations. On freshly booted system where all CPUs are
in good condition, the fast reboot works fine. But fast reboot fails when
any of the COREs are GARDed by Service processor. This is because xscom
operations fails/timeout on the CPUs/COREs that are GARDed. Fix this issue
by skipping GARDed CPUs during fast reboot path.
The GARDed CPUs are presented as 'bad' to OPAL and OPAL marks that
cpu->state as 'cpu_state_unavailable'. This patch checks the cpu state
to skip GARDed CPUs during fast reboot.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Recent changes to the skiboot resource loading code means that reads for
BOOTKERNEL and ROOTFS partitions will be exactly the number of bytes
required and no longer the (inaccurate) partition total size which
happened to be block size aligned.
Error when booting in mambo:
1140078: (1140078): [ 0.001132323,3] FLASH: failed to read content
size 14252376 BOOTKERNEL partition, rc -1
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
[initial review and changes by Mikey Neuling]
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Resource loading uses the flash calls directly which works on hardware
as the blocklevel abstraction was initialised with a flash structure. On
platforms such as mambo the blocklevel abstraction was initialised with
the bogusdisk structure so calling the flash calls directly results in
following uninitialised function pointers off into lala land.
Functionality is preserved as the blocklevel is told if a flash
partition is ECC protected during the call to ffs_init().
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This fixes tpm_extendl() to measure only when the list of
registered tpms is not empty.
Fixes: 3837c6f0cf4cffb5de874413eed755c0c698b076
Signed-off-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Currently, the tpm_extendl() results are logged by the caller, but
tpm_extendl() walks through all the tpm_chip registered and consequently
multiple tpm_chips can fail.
This turns the logging over to tpm_extendl(), which now logs how many
tpm_chips successfully measured and failed to measure a given data.
Another option would be to provide the caller the number of tpm_chips
that failed and successfully measured the data, but the caller will use
this information only for logging.
Signed-off-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Each tpm_chip structure is associated with one tpm device and one firmware
event log. If tpm_extendl() returns when the first tpm_chip operation (pcr
extend or event log record) fails, the remaining registered tpm_chips will be
in an inconsistent state, i.e, missing one measurement.
This walks through all registered tpm_chips and disable all tpm_chips that
failed rather than only first one.
Signed-off-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: assert(tpm) in disable_tpm]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We always verify and measure an image as a whole, never its subpartition
(if exists).
This removes the subid argument from sb_verify() and tb_measure()
functions, and also reflects the change to the callers, STB interface
and STB documentation.
Signed-off-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This just do some line breaking in the flash_load_resource() function.
Signed-off-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: reword commit message]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This removes the toc var. It is allocated in the function, but not used.
Signed-off-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This greatly simplifies the build process for travis, yet makes it more
powerful and increases coverage without increasing wall time to test.
Travis has the concept of a build matrix, and we want to ensure we continue
to build succesfully on a variety of platforms and compiler combinations.
We limit what we run on some OSs to conserve vital sanity.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
With a modern GCC targetting ARM 32-bit:
gard.c: In function 'main':
gard.c:652:19: error: format '%lu' expects argument of type 'long
unsigned int', but argument 4 has type 'uint64_t {aka long long
unsigned int}' [-Werror=format=]
fprintf(stderr, "MTD device bigger than %i: size:%lu\n",
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
opal-prd is supposed to run only on ppc64(le) hosts with support for
diagnostics. The presence of the following device-tree node will indicate
a system that supports PRD:
/sys/firmware/devicetree/base/ibm,opal/diagnostics
Signed-off-by: Rafael Fonseca <rdossant@redhat.com>
[stewart@linux.vnet.ibm.com: drop ppc64le arch req, DT is enough&we run on BE]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This gets us syntax highlighting of device tree snippets.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Unlike the rest of skiboot, DtsLexer.py is BSD licensed as it
should go into the pygments project (Python library for doing
syntax highlighting which is used by Sphinx).
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
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>
|