| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Explictly load powernv_flash module on BMC based system so that we are sure
that flash device is created before starting opal-prd daemon.
Note that I have replaced pnor_available() check with is_fsp_system(). As we
want to load module on BMC system only. Also pnor_init has enough logic to
detect flash device. Hence pnor_available() becomes redundant check.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
CC: Jeremy Kerr <jeremy.kerr@au1.ibm.com>
CC: Stewart Smith <stewart@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The blocklevel abstraction allows for regions of the backing store to be
marked as ECC protected so that blocklevel can decode/encode the ECC
bytes into the buffer automatically without the caller having to be ECC
aware.
Unfortunately this abstraction is far from perfect, this is only useful
if reads and writes are performed at the start of the ECC region or in
some circumstances at an ECC aligned position - which requires the
caller be aware of the ECC regions.
The problem that has arisen is that the blocklevel abstraction is
initialised somewhere but when it is later called the caller is unaware
if ECC exists in the region it wants to arbitrarily read and write to.
This should not have been a problem since blocklevel knows. Currently
misaligned reads will fail ECC checks and misaligned writes will
overwrite ECC bytes and the backing store will become corrupted.
This patch add the smarts to blocklevel_read() and blocklevel_write() to
cope with the problem. Note that ECC can always be bypassed by calling
blocklevel_raw_() functions.
All this work means that the gard tool can can safely call
blocklevel_read() and blocklevel_write() and as long as the blocklevel
knows of the presence of ECC then it will deal with all cases.
This also commit removes code in the gard tool which compensated for
inadequacies no longer present in blocklevel.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Tested-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
[stewart: core/flash: Adapt to new libflash ECC API
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
| |
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
| |
This also updated the pflash tests which use ffspart to generate pnors
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An FFS TOC is comprised of two parts. A small header which has a magic
and very minimmal information about the TOC which will be common to all
partitions, things like number of patritions, block sizes and the like.
Following this small header are a series of entries. Importantly there
is always an entry which encompases the TOC its self, this is usually
called the 'part' partition.
Currently libffs always assumes that the 'part' partition is at zero.
While there is always a TOC and zero there doesn't actually have to be.
PNORs may have multiple TOCs within them, therefore libffs needs to be
flexible enough to allow callers to specify TOCs not at zero.
The 'part' partition is otherwise a regular partition which may have
flags associated with it. libffs should allow the user to set the flags
for the 'part' partition.
This patch achieves both by allowing the caller to specify the 'part'
partition. The caller can not and libffs will provide a sensible
default.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently consumers can add an new ffs entry to multiple headers, this
is fine but freeing any of the headers will cause the entry to be freed,
this causes double free problems.
Even if only one header is uses, the consumer of the library still has a
reference to the entry, which they may well reuse at some other point.
libffs will now refcount entries and only free when there are no more
references.
This patch also removes the pointless return value of ffs_hdr_free()
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
| |
Since the libffs no longer needs to sort the entries as they get added
it makes little sense to have the complexity of a linked list when an
array will suffice.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out this code was messy and not all that reliable. Doing it at
the library level adds complexity to the library and restrictions to the
caller.
A simpler approach can be achived with the just instantiating multiple
ffs_header structures pointing to different parts of the same file.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
These options are currently flakey in libflash/libffs so there isn't
much point to being able to use them in ffspart.
Future reworks planned for libflash/libffs will render these options
redundant anyway.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
| |
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
It seems we've developed a character respresentation for ffs partition
flags. Currently only pflash really prints them so it hasn't been a
problem but now ffspart wants to read them in from user input.
It is important that what libffs reads and what pflash prints remain
consistent, we should move the code into libffs to avoid problems.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
| |
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
| |
When clearing gard records, Hostboot only modifies the record_id
portion to be 0xFFFFFFFF. The remainder of the entry remains.
Without this change it can be confusing to users to know that
the record they are looking at is no longer valid.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Newer firmwares report some feature flags related to security
settings via HDAT. On real hardware skiboot translates these into
device tree properties. For testing purposes just create the
properties manually in the tcl.
These values don't exactly match any actual chip revision, but the
code should not rely on any exact set of values anyway. We just define
the most interesting flags, that if toggled to "disable" will change
Linux behaviour. You can see the actual values in the hostboot source
in src/usr/hdat/hdatiplparms.H.
Also add an environment variable for easily toggling the top-level
"security on" setting.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise we could end up trying to build files before the links
are created.
Let's use a heavy handed approach and not build *anything* until
we have the links.
Reported-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
i2c.c fails to compile with gcc7 and -Werror=format-overflow used in
Debian Unstable and Ubuntu 18.04 :
i2c.c: In function ‘i2c_init’:
i2c.c:211:15: error: ‘%s’ directive writing up to 255 bytes into a
region of size 236 [-Werror=format-overflow=]
dpath is supposed to store an entire path.
Reported-by: Michel Normand <michel.mno@free.fr>
Signed-off-by: Frédéric Bonnard <frediz@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
In Debian/Ubuntu, the packaging system likes to have a full cleanup that
restores the tree back to original one, so add some files to the distclean
target.
Signed-off-by: Frédéric Bonnard <frediz@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
| |
For the need of Debian/Ubuntu packaging, I infered some initial man
pages from their help output.
Signed-off-by: Frédéric Bonnard <frediz@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
We *disable* the secure boot part, but we keep the verified boot
part as we don't currently have container verification code for Mambo.
We can run a small part of the code currently though.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The write(2) system call returns the number of bytes written, this is
important since it is entitled to write less than what we requested.
Currently we ignore the return value and assume it wrote everything we
requested. While in practice this is likely to always be the case, it
isn't actually correct.
This patch addresses this.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support to handle OCC load/start event from FSP/PRD.
During IPL we send a success directly to FSP without invoking any HBRT
load routines on recieving OCC load mbox message from FSP. At runtime
we forward this event to host opal-prd.
This patch provides support for invoking OCC load/start HBRT routines
like load_pm_complex() and start_pm_complex() from opal-prd.
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
This patch handles OCC_RESET runtime events in host opal-prd and also
provides support for calling 'hostinterface->wakeup()' which is
required for doing the reset operation.
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Acked-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
i.e. we get a hash rather than a version number
This seems to be occuring in Travis if it doesn't pull a tag.
Fixes: 41f51c834a1be508ca2e7446fe8fa6abc3af473c
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the misc flag clear_on_ecc_error to libflash/pflash. This was
the only missing flag. The generator of the virtual pnor image
relies on libflash/pflash to provide the partition information,
so all flags are needed to build an accurate virtual pnor partition
table.
Signed-off-by: Adriana Kobylak <anoo@linux.vnet.ibm.com>
Reviewed-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
For some bizarre reason, Travis started failing on this
substitution when there'd been zero code changes in this
area... This at least papers over whatever the problem is
for the time being.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When performing a read the return value from pflash is non-zero, even for
a successful read, when the size being read is not a multiple of 256.
This is because do_read_file returns the value from the write system
call which is then returned by pflash. When the size is a multiple of
256 we get lucky in that this wraps around back to zero. However for any
other value the return code is size % 256. This means even when the
operation is successful the return code will seem to reflect an error.
Fix this by returning zero if the entire size was read correctly,
otherwise return the corresponding error code.
Fixes: e1cf130d ("external/pflash: Remove use of exit() and fix memory leaks")
Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Reviewed-by: Cyril Bur <cyrilbur@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
| |
I hear Stewart likes these for some reason. Dunno why.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
The return value of a subcommand is interpreted as a libflash error code
when it's positive or some subcommand specific error when negative.
Currently the create subcommand always returns zero when exiting (even
for errors) so fix that.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
| |
This comment referred to some previously deleted code. It can go.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
| |
The -p argument only really makes sense when -f is specified. Print an
actual error message rather than just the usage blob.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
| |
There's an entire byte for the instance count rather than a nibble. Only
barf if the instance number is beyond 255 rather than 16.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
Currently we assume that the Unit ID can be used as an array index into
the chip_units[] structure. There are holes in the ID space though, so
this doesn't actually work. Fix it up by walking the array looking for
the ID.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we assume that this tool is being used on a P8 system by
default and allow the user to override this behaviour using the -8 and
-9 command line arguments. When running on the host we can use the
PVR to guess what chip generation so do that.
This also changes the default behaviour to assume that the host is a P9
when running on an ARM system. This tool didn't even work when compiled
for ARM until recently and the OpenBMC vPNOR hack that we have currently
is broken for P9 systems that don't use vPNOR (Zaius and Romulus).
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
We currently assume that a record with an ID of 0xffffffff is invalid.
Apparently this is incorrect and we should display these records, so
expand the check to compare the entire record with 0xff rather than
just the ID.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
Currently running 'make check' results in nothing but a message
indicating that all tests passed. If a test runs in a wood and it
doesn't make a sound, did it run at all?
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the mambo scripts can do multiple chips, but only the first
ever has memory.
This patch adds support for having memory on each chip, with each
appearing as a separate NUMA node. Each node gets MEM_SIZE worth of
memory.
It's opt-in, via export MAMBO_NUMA=1.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
| |
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
Print some information about the failing test rather than forcing the
user to go dig it up. Also move the stdout and stderr files into the
test directory to make the relevant stdout/stderr files easier to
locate.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
The plugin seems to be the preferred way to do this now, it works
better, and the qtracer emitter seems to generate invalid traces
in new mambo versions.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is possible to erase within a single erase block. Currently the
pflash code assumes that if the erase starts part way into an erase
block it is because it needs to be aligned up to the boundary with the
next erase block.
Doing an erase smaller than a single erase block will cause underflows
and looping forever on erase.
Fixes: ae6cb86c2 ("external/pflash: Reinstate the progress bars")
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
A big-ol-hack to add some checking for OpenBMC's vPNOR GUARD files under
/media/pnor-prsv. This isn't ideal since it doesn't handle the create
case well, but it's better than nothing.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
Direct mode is generally either unsafe or unsupported. We should always
access the PNOR via an MTD device so make that the default. If someone
really needs direct mode, then they can use pflash.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new sub-command that allows us to create GARD records for
arbitrary chip units. There isn't a whole lot of constraints on this and
that limits how useful it can be, but it does allow a user to GARD out
individual DIMMs, chips or cores from the BMC (or host) if needed.
There are a few caveats though:
1) Not everything can, or should, have a GARD record applied it to.
2) There is no validation that the unit actually exists. Doing that
sort of validation requires something that understands the FAPI
targeting information (I think) and adding support for it here
would require some knowledge from the system XML file.
3) There's no way to get a list of paths in the system.
4) Although we can create a GARD record at runtime it won't be applied
until the next IPL.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
| |
In order to support manual GARD records we need to be able to parse the
hardware unit path strings. This patch implements that.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
Display the full aath to the GARDed hardware unit in each record rather
than relying on the output of `gard show` and convert do_list() to use
the iterator while we're here.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The output of `gard list` has a field named "Type", however this
doesn't actually indicate the type of the record. Rather, it
shows the type of the path used to identify the hardware being
GARDed. This is of pretty dubious value considering the Physical
path seems to always be used when referring to GARDed hardware.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
| |
Starting coverting code to use the iterators and fix some bad naming
along the way.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
Add a `for_each_gard` iterator rather than using do_iterate. Callbacks
are banned under the Genoa convention and we need to apply a
zero-tolerance policy.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
| |
It was annoying me.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
| |
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|