| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Suggested-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
| |
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
| |
Caught by scan-build. We rewrite ecc_len with a different
value prior to use
Signed-off-by: Balbir singh <bsingharora@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
| |
Caught by scan-build, we seem to trap the errors in rc, but
not take any recovery action during blocklevel_write.
Signed-off-by: Balbir singh <bsingharora@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
| |
Caught by scan-build, attn is passed in by value and modified
but not read after that.
Signed-off-by: Balbir singh <bsingharora@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We get the same code generation using the builtin:
GCC 7.3:
a3584: 7d 29 00 f4 popcntb r9,r9
a3588: 7d 29 01 74 prtyd r9,r9
GCC 6.3:
a0bfc: 7d 29 00 f4 popcntb r9,r9
a0c00: 7d 29 01 74 prtyd r9,r9
Clang 7 (and clang 6):
bd48c: 7c e7 03 f4 popcntd r7,r7
bd490: 54 e7 07 fe clrlwi r7,r7,31
(Not sure why the clang builtin generates different code)
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
| |
Signed-off-by: Pridhiviraj Paidipeddi <ppaidipe@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently all ecc_protected() does is say if a region is ECC protected
or not. Knowing a region is ECC protected is one thing but there isn't
much that can be done afterwards if this is the only known fact. A lot
more can be done if the caller is told where the ECC region begins.
Knowing where the ECC region start it allows to caller to align its
read/and writes. This allows for more flexibility calling read and write
without knowing exactly how the backing store is organised.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
As part of ongoing work to make ECC invisible to higher levels up the
stack this function converts a 'position' which should be ECC agnostic
to the equivalent position within an ECC region starting at a specified
location.
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>
|
|
|
|
|
|
|
| |
Not all TOCs are written at zero
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
It turns out that sorted order isn't the best idea. This removes
flexibility from the caller. If the user wants their partitions in
sorted order, they should insert them in sorted order.
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>
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rebooting a BMC can take 70 seconds. Skiboot cannot possibly spin for
70 seconds waiting for a BMC to come back. This also makes the current
default of 30 seconds a bit pointless, is it far too short to be a
worse case wait time but too long to avoid hitting hardlockup detectors
and wrecking havoc inside host linux.
Just change it to three seconds so that host linux will survive and
that, reads and writes will fail but at least the host stays up.
Also refactored the waiting loop just a bit so that it's easier to read.
Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Tested-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bugs present in the BMC daemon mean that skiboot gets presented with
mbox windows of size zero. These windows cannot be valid and skiboot
already detects these conditions.
Currently skiboot warns quite strongly about the occurrence of these
problems. The problem for skiboot is that it doesn't take any action.
Initially I wanting to avoid putting policy like this into skiboot but
since these bugs aren't going away and skiboot barfing is leading to
lockups and ultimately the host going down something needs to be done.
I propose that when we detect the problem we fail the mbox call and punt
the problem back up to Linux. I don't like it but at least it will cause
errors to cascade and won't bring the host down. I'm not sure how Linux
is supposed to detect this or what it can even do but this is better
than a crash.
Diagnosing a failure to boot if skiboot its self fails to read flash may
be marginally more difficult with this patch. This is because skiboot
will now only print one warning about the zero sized window rather than
continuously spitting it out.
Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Tested-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes to build system to use thin archives rather than
incremental linking for built-in.o, similar to recent change to Linux.
built-in.o is renamed to built-in.a, and is created as a thin archive
with no index, for speed and size. All built-in.a are aggregated into
a skiboot.tmp.a which is a thin archive built with an index, making it
suitable or linking. This is input into the final link.
The advantags of build size and linker code placement flexibility are
not as great with skiboot as a bigger project like Linux, but it's a
conceptually better way to build, and is more compatible with link
time optimisation in toolchains which might be interesting for skiboot
particularly for size reductions.
Size of build tree before this patch is 34.4MB, afterwards 23.1MB.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If blocklevel_smart_erase() detects that the smart erase fits entire in
one erase block, it has an early bail path. In this path it miscaculates
where in the buffer the backend needs to read from to perform the final
write.
Fixes: d6a5b53f ("libflash/blocklevel: Add blocklevel_smart_erase()")
Fixes: https://github.com/open-power/skiboot/issues/151
Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Tested-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some BMC mbox implementations seem to sometimes mysteriously fail when trying
to negotiate v3 when they only support v2. To work around this, we
can fall back to requesting lower mbox protocol versions until we find
one that works.
In theory, this should already "just work", but we have a counter example,
which this patch fixes.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
| |
This makes the mbox unit test run 300x quicker and seems to
shave about 6 seconds from boot time on Witherspoon.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A first basic set of tests for mbox-flash. These tests do their testing
by stubbing out or otherwise replacing functions not in
libflash/mbox-flash.c. The stubbed out version of the function can then
be used to emulate a BMC mbox daemon talking to back to the code in
mbox-flash and it can ensure that there is some adherence to the
protocol and that from a blocklevel api point of view the world appears
sane.
This makes these tests simple to run and they have been integrated into
`make check`. The down side is that these tests rely on duplicated
feature incomplete BMC daemon behaviour. Therefore these tests are a
strong indicator of broken behaviour but a very unreliable indicator of
correctness.
Full integration tests with a 'real' BMC daemon are probably beyond the
scope of this repository.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
[stewart: fix TESTS_LOOPS printf]
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>
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hw/lpc-mbox no longer requires that the memory associated with messages
exist for the lifetime of the message. Once it has been sent to the BMC,
that is bmc_mbox_enqueue() returns, lpc-mbox does not need the message
to continue to exist. On the reciving side, lpc-mbox will ensure that a
message exists for the receving callback function.
Remove all code to deal with allocating messages.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently when mbox-flash decides that a message times out the driver
has no way of knowing to drop the message and will continue waiting for
a response indefinitely preventing more messages from ever being sent.
This is a problem if the BMC crashes or has some other issue where it
won't ever respond to our outstanding message.
This patch provides a method for mbox-flash to tell the driver how long
it should wait before it no longer needs to care about the response.
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MBOX protocol states that if an open window command fails then all
open windows are closed. Currently, if an open window command fails
mbox-flash will erroneously assume that the previously open window is
still open.
The solution to this is to mark all windows as closed before issuing an
open window command and then on success we'll mark the new window as
open.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
To calculate the ECC syndrome we need to calculate the parity of a 64bit
number. On non-powerpc platforms we use the gcc builtin function
__builtin_parityl() to do this calculation. This is broken on 32bit ARM
where sizeof(unsigned long) is four bytes. Using __builtin_parityll()
instead cures this.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
The volatile flag was added to the pnor image to
indicate partitions that are cleared during a host
power off. Display this flag from the pflash command.
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
| |
while this is PR_DEBUG, and we shouldn't be printing it to the
console, we do because of a long standing bug in how we do
log priorities. So, for the moment at least, just don't print
it at all.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
Currently we don't move the buffer along for a short read() or write()
and nor do we request only the remaining amount.
Fixes: c7c3a4cd53d libflash/file: Add a file access backend to for the blocklevel interface.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Reviewed-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
==8304==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4096 byte(s) in 1 object(s) allocated from:
#0 0x7f70eda8f850 in malloc (/lib64/libasan.so.4+0xde850)
#1 0x408ba0 in main libflash/test/test-blocklevel.c:298
#2 0x7f70ec8e1509 in __libc_start_main (/lib64/libc.so.6+0x20509)
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
LeakSanitizer caught this with libflash/test/test-flash.c:
Direct leak of 4096 byte(s) in 1 object(s) allocated from:
#0 0x7f72546ee850 in malloc (/lib64/libasan.so.4+0xde850)
#1 0x405ff0 in flash_init libflash/test/../libflash.c:830
#2 0x408632 in main libflash/test/test-flash.c:382
#3 0x7f7253540509 in __libc_start_main (/lib64/libc.so.6+0x20509)
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
LeakSanitizer spotted this:
Direct leak of 131072 byte(s) in 1 object(s) allocated from:
#0 0x7fb99e42b850 in malloc (/lib64/libasan.so.4+0xde850)
#1 0x408612 in main libflash/test/test-flash.c:380
#2 0x7fb99d27d509 in __libc_start_main (/lib64/libc.so.6+0x20509)
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we extend the ECC protection array and subsequently decide to merge
regions in one call then there would be a use after free bug. While this
exists in theory and was caught by Coverity, it should never happen
since we only merge regions if we're low on space but the cause of the
use after free is due to having just created more space.
Nevertheless, this is the kind of ticking timebomb that simply requires
some code rearrangement or different 'optimisations' to become possible.
Best to just make it impossible.
Fixes CID 145924
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
libflash/libflash.c:
line 369: chunk = 0x100 - (d & 0xff);
line 370: if (chunk > 0x100)
At condition chunk > 256U, the value of chunk must be between 1 and 256.
Fixes CID 97821
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes: CID 142226 (#1 of 1):
overflow_before_widen: Potentially overflowing expression
`1 << mbox_flash->shift` with type int (32 bits, signed) is evaluated using
32-bit arithmetic, and then used in a context that expects an expression
of type uint64_t (64 bits, unsigned).
Fixes: CID 142226
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New code that is very much pflash functionality was added in commit
f2c87a3d2f6 "pflash option to retrieve PNOR partition flags".
Unfortunately at the time there wasn't an easy way to test pflash.
The previous patch adds pflash infrastructure and plumbs it into
`make check` nicely. This commit converts the tests originally added to
libflash 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>
|