| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fix endian for the 4-byte LPC copy similarly to other flash drivers.
This allows flash to be detected on POWER8 AST BMC systems with a LE
skiboot.
Fix incorrect comments in those other drivers while we're here.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
SPDX makes it a simpler diff.
I have audited the commit history of each file to ensure that they are
exclusively authored by IBM and thus we have the right to relicense.
The motivation behind this is twofold:
1) We want to enable experiments with coreboot, which is GPLv2 licensed
2) An upcoming firmware component wants to incorporate code from skiboot
and code from the Linux kernel, which is GPLv2 licensed.
I have gone through the IBM internal way of gaining approval for this.
The following files are not exclusively authored by IBM, so are *not*
included in this update (I will be seeking approval from contributors):
core/direct-controls.c
core/flash.c
core/pcie-slot.c
external/common/arch_flash_unknown.c
external/common/rules.mk
external/gard/Makefile
external/gard/rules.mk
external/opal-prd/Makefile
external/pflash/Makefile
external/xscom-utils/Makefile
hdata/vpd.c
hw/dts.c
hw/ipmi/ipmi-watchdog.c
hw/phb4.c
include/cpu.h
include/phb4.h
include/platform.h
libflash/libffs.c
libstb/mbedtls/sha512.c
libstb/mbedtls/sha512.h
platforms/astbmc/barreleye.c
platforms/astbmc/garrison.c
platforms/astbmc/mihawk.c
platforms/astbmc/nicole.c
platforms/astbmc/p8dnu.c
platforms/astbmc/p8dtu.c
platforms/astbmc/p9dsu.c
platforms/astbmc/vesnin.c
platforms/rhesus/ec/config.h
platforms/rhesus/ec/gpio.h
platforms/rhesus/gpio.c
platforms/rhesus/rhesus.c
platforms/astbmc/talos.c
platforms/astbmc/romulus.c
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
[oliver: fixed up the drift]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
This requires a small change to flash drivers which assumed 4-byte LPC
reads would not change endian. _raw accessors could be added if this
becomes a signifcant pattern, but for now this hack works.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Reads explicitly validate window state after the LPC operations have
completed, but this is not necessary in the write path. Explicitly
document the behaviour to make the implicit behaviour clear to future
readers.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
During boot SBE and early hostboot does not use HIOMAP protocol to get image
from PNOR. Instead it expects PNOR TOC and Hostboot Boot Loader to be
available at particular address in LPC bus. mbox daemon in BMC side takes
care of this during normal boot. Once boot is complete mbox daemon switches
to normal mode.
During normal reboot, BMC side mbox daemon gets notification and takes care of
loading PNOR TOC and HBBL to LPC bus again.
In MPIPL path, OPAL calls SBE S0 interrupt to initiate MPIPL. BMC will not be
aware of this. But SBE expects PNOR TOC and HBBL to be available in LPC bus at
predefined address. Hence call HIOMAP Reset from OPAL in assert path.
This needs working LPC and IPMI driver in OPAL. If we have issue in these
drivers then we may not be able to reset BMC MBOX properly. Hence MPIPL may
fail. We have to live with this until we find a way to intiate BMC on MPIPL.
CC: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
[oliver: rebased]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Use Software Package Data Exchange (SPDX) to indicate license for each
file that is unique to skiboot.
At the same time, ensure the (C) who and years are correct.
See https://spdx.org/
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
[oliver: Added a few missing files]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
We convert data size to block count and pass block count to BMC.
If data size is not block aligned then we endup sending block count
less than actual data. BMC will write partial data to flash memory.
Sample log :
[ 594.388458416,7] HIOMAP: Marked flash dirty at 0x42010 for 8
[ 594.398756487,7] HIOMAP: Flushed writes
[ 594.409596439,7] HIOMAP: Marked flash dirty at 0x42018 for 3970
[ 594.419897507,7] HIOMAP: Flushed writes
In this case HIOMAP sent data with block count=0 and hence BMC didn't
flush data to flash.
Lets fix this issue by adjusting block count before sending it to BMC.
Cc: Andrew Jeffery <andrew@aj.id.au>
Cc: skiboot-stable@lists.ozlabs.org
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
The protocol defines the response to the associated messages as empty
except for the command ID and sequence fields. If the BMC is returning
extra data consider the message malformed.
Cc: stable
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Issuing a HIOMAP_C_CLOSE is not required by the protocol specification,
rather a close can be implicit in a subsequent
CREATE_{READ,WRITE}_WINDOW request. The implicit close provides an
opportunity to reduce LPC traffic and the implementation takes up that
optimisation, so remove the case from the IPMI callback handler.
Cc: stable
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Reworking the event handling was inspired by a bug report by Vasant
where the host would get wedged on multiple flash access attempts in the
face of a persistent error state on the BMC-side. The cause of this bug
was the early-exit based on ctx->update, which erronously assumed that
all events had been completely handled in prior calls to
ipmi_hiomap_handle_events(). This is not true if e.g.
HIOMAP_E_DAEMON_READY is clear in the prior calls.
Regardless, there were other correctness and efficiency problems with
the handling strategy:
* Ack-able event state was not restored in the face of errors in the
process of re-establishing protocol state
* It forced needless window restoration with respect to the context in
which ipmi_hiomap_handle_events() was called.
* Tests for HIOMAP_E_DAEMON_READY and HIOMAP_E_FLASH_LOST were redundant
with the overhauled error handling introduced in the previous patch
Fix all of the above issues and add comments to explain the event
handling flow.
Tests for correctness follow later in the series.
Cc: stable
Cc: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
The aim is to improve the robustness with respect to absence of the
BMC-side daemon. The current error handling roughly mirrors what was
done for the mailbox implementation, but there's room for improvement.
Errors are split into two classes, those that affect the transport state
and those that affect the window validity. From here, we push the
transport state error checks right to the bottom of the stack, to ensure
the link is known to be in a good state before any message is sent.
Window validity tests remain as they were in the hiomap_window_move()
and ipmi_hiomap_read() functions. Validity tests are not necessary in
the write and erase paths as we will receive an error response from the
BMC when performing a dirty or flush on an invalid window.
Recovery also remains as it was, done on entry to the blocklevel
callbacks. If an error state is encountered in the middle of an
operation no attempt is made to recover it on the spot, instead the
error is returned up the stack and the caller can choose how it wishes
to respond.
Cc: stable
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Cc: stable
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
This isn't *necessarily* an error that we should complain loudly about.
If, for example, the BMC enforces the Read Only flag on a FFS partition,
opening a write window *should* fail, and we do indeed test this in
op-test.
Thus we deal with the error in a well known path: returning an error
code and then it's eventually a userspace problem.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Fix the fix of ORing in the BMC state - we only want to retain state
covered by the ack mask as this is something we still need to handle.
Critically, we must not retain state not covered by the ack mask as this
may lead to host firmware attempting to communicate with a dead daemon
or attempting to access the PNOR whilst the daemon is not in control of
the flash.
Further, add unit tests to capture the desired (and now implemented)
behaviour.
Fixes: 34cffed2ccf3 ("libflash/ipmi-hiomap: Improve event handling")
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Lay the ground work for unit testing the ipmi-hiomap implementation. The
design hooks a subset of the IPMI interface to move through a
data-driven "scenario" of IPMI message exchanges. Two basic tests are
added exercising the initialsation path of the protocol implementation.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
libflash/ipmi-hiomap.c: In function ‘hiomap_window_move’:
libflash/ipmi-hiomap.c:17:21: error: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Werror=format=]
#define pr_fmt(fmt) "HIOMAP: " fmt
^~~~~~~~~~
include/skiboot.h:93:41: note: in expansion of macro ‘pr_fmt’
#define prlog(l, f, ...) do { _prlog(l, pr_fmt(f), ##__VA_ARGS__); } while(0)
^~~~~~
include/skiboot.h:94:30: note: in expansion of macro ‘prlog’
#define prerror(fmt...) do { prlog(PR_ERR, fmt); } while(0)
^~~~~
libflash/ipmi-hiomap.c:291:3: note: in expansion of macro ‘prerror’
prerror("Invalid window properties: len: %llu, size: %llu\n",
^~~~~~~
libflash/ipmi-hiomap.c:291:47: note: format string is defined here
prerror("Invalid window properties: len: %llu, size: %llu\n",
~~~^
%lu
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Admittedly the situations are pretty dire, and usually indicate a
programming failure on the BMC's part, but abort() seems a bit over the
top. The technique was useful for development but shouldn't have made it
into production.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
The initial implementation of ipmi-hiomap left a bit to be desired when
it came to event handling: it didn't completely restore the state of the
system to what it was before events like a hiomap protocol or window
reset take place. The result is the host cannot recover from e.g. the
BMC being rebooted underneath it.
Take the only step required in the event of window reset, or the final
step after performing the handshake in the event of a protocol reset,
and re-open the previously active window if there was one.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
The host firmware side of the hiomap protocol has two input sources:
1. Requests to adjust the flash mappings from itself or the kernel
2. State change events received from the BMC
The handling of BMC state change events (2.) is asynchronous in two ways:
a. The BMC pushes the state change event to the host, which is recorded
but not acted on
b. When handling requests to adjust the flash mapping, skiboot first
addresses any new BMC state changes before servicing the mapping
request
Further, the hiomap protocol sends a mix of ackable and stateful events,
where ackable events are only relevant until skiboot's hiomap event
handler (b. above) cleans them up, whereas stateful events persist until
the BMC provides a subsequent state change event.
As we handle the ackable events asynchronous to receiving notification
(b. vs a. above), OR in the received event state rather than directly
assign to ensure we don't lose events that we must not miss. As an
example, without the OR we may lose ackable events if the daemon
restarts and pushes a new state change event during initialisation,
which will necessarily bear no relation to the previous state change
event value.
Similarly, don't close active windows in a. based on the event content,
as we need the window type information to handle state restoration in b.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Previously we were leaking the memory pointed by ctx if an IPMI error
occurred during protocol initialisation. Make sure we free the memory if
an error occurs.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Fixes: 529bdca0bc546a7ae3ecbd2c3134b7260072d8b0
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Otherwise we'd slowly leak memory on each hiomap operation.
Fixes: 529bdca0bc546a7ae3ecbd2c3134b7260072d8b0
Tested-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Segregate the BMC platform configuration into hardware and software
components. This allows population of platform default values for
hardware configuration that may no-longer be accessible by the host.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
[stewart: fixup pci-quirk unit test]
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
ipmi-hiomap implements the PNOR access control protocol formerly known
as "the mbox protocol" but uses IPMI instead of the AST LPC mailbox as a
transport. As there is no-longer any mailbox involved in this alternate
implementation the old protocol name is quite misleading, and so it has
been renamed to "the hiomap protoocol" (Host I/O Mapping protocol). The
same commands and events are used though this client-side implementation
assumes v2 of the protocol is supported by the BMC.
The code is a heavily-reworked copy of the mbox-flash source and is
introduced this way to allow for the mbox implementation's eventual
removal.
mbox-flash should in theory be renamed to mbox-hiomap for consistency,
but as it is on life-support effective immediately we may as well just
remove it entirely when the time is right.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
[stewart: prlog debug over prerror for mbox fallback, fix indent]
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
