| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`make coverage-report` gave the following error:
(cd external/pflash; lcov -q -c -d . -o pflash.info --rc lcov_branch_coverage=1; sed -i -e 's%external/pflash/libflash%libflash%; s%external/pflash/ccan%ccan%' pflash.info)
(cd external/gard; lcov -q -c -d . -o gard.info --rc lcov_branch_coverage=1; sed -i -e 's%external/gard/libflash%libflash%; s%external/gard/ccan%ccan%' gard.info)
geninfo: WARNING: no .gcda files found in . - skipping!
geninfo: WARNING: no .gcda files found in . - skipping!
lcov -q -c -d . -d ccan/check_type/test/ -d ccan/str/test/ -d ccan/str/test/ -d ccan/list/test/ -d ccan/list/test/ -d ccan/list/test/ -d ccan/list/test/ -d ccan/list/test/ -d ccan/build_assert/test/ -d ccan/short_types/test/ -d ccan/short_types/test/ -d ccan/array_size/test/ -d ccan/container_of/test/ -d ccan/endian/test/ -d libc/test/ -d libc/test/ -d libc/test/ -d libc/test/ -o skiboot.info --rc lcov_branch_coverage=1
lcov -q -r skiboot.info 'external/pflash/*' -o skiboot.info
lcov -q -r skiboot.info 'external/gard/*' -o skiboot.info
lcov -q -a skiboot.info -a external/pflash/pflash.info -o skiboot.info
lcov: ERROR: no valid records found in tracefile external/pflash/pflash.info
make: *** [/home/andrew/src/open-power/skiboot/Makefile.main:315: skiboot.info] Error 255
And similar again for the gard tool. We should really untangle the build
strategy for tools in external/, but in the mean time paper over the
problem of generating the lcov output at the top level by ensuring we
have a means to generate the necessary gcda files for lcov to consume.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gard.c:285:5: error: no previous prototype for ‘parse_path’ [-Werror=missing-prototypes]
int parse_path(const char *str, struct entity_path *parsed)
^~~~~~~~~~
gard.c: In function ‘do_list’:
gard.c:459:46: error: unused parameter ‘argc’ [-Werror=unused-parameter]
static int do_list(struct gard_ctx *ctx, int argc, char **argv)
~~~~^~~~
gard.c:459:59: error: unused parameter ‘argv’ [-Werror=unused-parameter]
static int do_list(struct gard_ctx *ctx, int argc, char **argv)
~~~~~~~^~~~
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
| |
|
|
|
|
|
| |
This warning appears to not be particularly useful if you ever
actually *want* to truncate a string.
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>
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Source the list of units from the hostboot source rather than the
previous hard coded list. The list of path element types changes
between generations so we need to add a level of indirection to
accommodate P9. This also changes the names used to match those
printed by Hostboot at IPL time and paves the way to adding support
for manual GARD record creation.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
| |
This field has never been populated by hostboot on OpenPower systems
so there's no real point in reporting it's contents.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using the current implementation of the gard tool to ecc clear the
entire GUARD partition it is done one gard record at a time. While this
may be ok when accessing the actual flash this is very slow when done
from the host over the mbox protocol (on the order of 4 minutes) because
the bmc side is required to do many read, erase, writes under the hood.
Fix this by rewriting the gard tool reset_partition() function. Now we
allocate all the erased guard entries and (if required) apply ecc to the
entire buffer. Then we can do one big erase and write of the entire
partition. This reduces the time to clear the guard partition to on the
order of 4 seconds.
Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Reviewed-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>
|
| |
|
|
|
|
|
|
|
|
|
| |
The reason for this is that check targets for one tool will start to
depend on other tools. For example, future pflash tests will rely on
ffspart to generate pnors. The current method is too racey and results
in races cleaning/building ffspart for its tests and for pflash tests.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Reviewed-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recent reworks were tested on the travis-ci system. Unfortunately, there
are configurations of running `make check` which the travis-ci doesn't
do. On some systems extra problems crop up.
Removing the stack size check is only done for the host compiler as the
check is only critical for skiboot its self where stack space is
contained.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Reviewed-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
| |
We end up with a bit of a nasty hack to count the libflash symlinks
in gard and pflash as part of libflash code coverage, but it does
work and is unlikely to break anytime soon.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
| |
Reviewed-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
| |
Mostly unused parameter warnings due to callbacks
Reviewed-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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several problems:
Firstly, it could never have worked, it was using the wrong variable.
Secondly, if it was using GARD_VERSION it produced a broken tarball that
still looked into the skiboot source for files despite them having been
copied into the tarball.
Lastly (and not really a make dist issue) the current way of symlinking
make_version.sh was racey. Get around the issue by refering to it in its
actual location (if we know it will be there) or by looking at .version
if building from tarball.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
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>
|
| |
|
|
|
|
|
|
|
| |
Let use LDFLAGS from the environment for gard and pflash
Debian/Ubuntu use this mechanism to do hardened builds.
Signed-off-by: Frederic Bonnard <frediz@linux.vnet.ibm.com>
[stewart@linux.vnet.ibm.com: also use LDFLAGS for pflash]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Commit fd599965 added some dependencies in 'external/pflash'
for libflash files that are created via symlink. Replicate
that same behavior in 'external/gard' to prevent race conditions
where we attempt to compile files from libflash before they are
symlink'd.
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the size of flash 64 bit safe so that we can have flash
devices greater than 4GB. This is especially useful for mambo disks
passed through to Linux.
Fortunately the device tree interface and the linux device driver are
64bit safe so no changes are required there.
Userspace gard and flash tools are also updated to ensure "make check"
still passes.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Reviewed-by: Cyril Bur <cyrilbur@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
| |
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
| |
While reviewing the Debian packaging, codespell found those.
Most proposed fixes are based on codespell's default dictionnary.
Signed-off-by: Frederic Bonnard <frediz@linux.vnet.ibm.com>
Reviewed-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gard can be used on the BMC to query garded records, but currently
compile fails with :
cc -O2 -Wall -Werror -I. -c gard.c -o gard.o
gard.c: In function 'do_clear_i':
gard.c:421:12: error: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'size_t' [-Werror=format]
gard.c: In function 'check_gard_partition':
gard.c:489:36: error: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'unsigned int' [-Werror=format]
This patches provides a fix compatible with x86, armel, ppc64.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
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: c51ceb9b9a380a7ed8e2af5b4d5e6c33386cd6f9
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
| |
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The makefiles under external/* utilize the $(CROSS_COMPILE) variable
to determine the cross-compiler prefix. In a few places,
$(CROSS_COMPILE)gcc is called instead of $(CC). The issue with this is
that yocto build passes some compile flags as part of $(CC) instead of
$(CFLAGS), the most important of these is '--sysroot=...'. Without the
proper --sysroot flag, pflash compile fails to find critical libc
headers like stdio.h.
This change delegates setting of $(CC) and $(LD) to
external/common/rules.mk, which is widely used in the external tree, and
ensures that:
1) $(CC) is used instead of $(CROSS_COMPILE)gcc.
2) CC is only set when not passed from the environment.
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
| |
Move symlinking target to external/common/rules.mk, so the rule
could be reused by gard and opal-prd.
Signed-off-by: Dinar Valeev <dvaleev@suse.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the file backend will keep a file descriptor open until the
structure is destroyed. This is undesirable for daemons and long running
processes that only have a very occasional need to access the file. Keeping
the file open requires users of blocklevel to close and reinit their
structures every time, doing is isn't disastrous but can easily be
managed at the interface level.
This has been done at the blocklevel_device interface so as to provide
minimal changes to arch_flash_init().
At the moment there isn't a need for the actually flash driver to be able
to do this, this remains unimplmented there.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a garded component is replaced hostboot detects this and updates the
gard partition.
What hostboot does is set the record_id field to 0xFFFFFFFF but leaves the
rest of the flash untouched, this has caused issues with the gard tool the
thinking was that an entire record of all 0xFF bytes would signal not a
valid record.
This patch add rectifies this issue and `gard list` will no longer show any
record with an id of 0xFFFFFFFF.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Reviewed-by: Sam Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
| |
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|