Age | Commit message (Collapse) | Author | Files | Lines |
|
[ Upstream commit f651e8eb56e2c17aeac58fd50c20f874d874169c ]
Fixes: 5b1bc2ffe791ae94361d86b2ae063ee543bf2df5
Signed-off-by: Stewart Smith <stewart@linux.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>
|
|
mostly missing prototypes and unused parameters.
Reviewed-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>
|
|
pflash relies on arch_flash_arm parsing /proc/mtd to discover the pnor
partition. It helpfully uses strcasestr so it can handle the string
changing, which is what has happened as we moved to upstream compliant
mtd device tree bindings.
We currently have a string like this:
dev: size erasesize name
mtd0: 00060000 00001000 "u-boot"
mtd1: 00020000 00001000 "u-boot-env"
mtd2: 00280000 00001000 "kernel"
mtd3: 001c0000 00001000 "initramfs"
mtd4: 01740000 00001000 "rofs"
mtd5: 00400000 00001000 "rwfs"
mtd6: 02000000 00001000 "1e620000.flash-controller:flash@1"
mtd7: 08000000 00001000 "1e630000.flash-controller:pnor@0"
Unfortunately arch_flash_arm assumes the string will be at most 50
characters. That's right before the label we're looking for starts so
we ignore that line and keep searching.
Fix it by allowing for a 255 character line.
Fixes: 48ab7ce09504 (external/pflash: Add --mtd)
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>
|
|
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>
|
|
Honestly the first name was terrible. Initially this was intended only
to serve for BMC/ARM flash access, however, it should be more generic as
it is in the external/common arch code it should play nice on all
architectures.
This change also paves the way to change the default flash access
methods in pflash.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Acked-by: Joel Stanley <joel@jms.id.au>
[stewart@linux.vnet.ibm.com: preserve Joel's ack]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
If the access method to the flash is PNOR_MTD or BMC_MTD then the
actual access is being done for us by the kernel. This means we don't
need to worry about wrprotecting. The arch level shouldn't be returning
an error, it should be fall though.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Acked-by: Joel Stanley <joel@jms.id.au>
[stewart@linux.vnet.ibm.com: preserve Joel's ack]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Arch headers need to be linked in before compiling.
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Building opal-prd currently leaves the git tree dirty. This fixes it.
Signed-off-by: Michael Neuling <mikey@neuling.org>
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>
|
|
The arch_flash_init() in arch_flash_x86.c doesn't actually check the return value
of file_init_path(), rather it is comparing the returned structure against NULL.
It is unsafe (and incorrect at the moment) to assume that file_init_path will
NULL this value on failure, it doesn't have to as it returns a value to
indicate success or failure.
The arch_flash_init() in arch_flash_powerpc.c calls file_init_path() through
another function which will return a pointer (or NULL on failure), this
function doesn't explicitly NULL its return pointer in the case that
file_init_path() fails. It has initialised the pointer to NULL so the case may
be less severe (compared to the arch_flash_x86 problem) as file_init_path()
shouldn't have changed it on failure case, however, assuming that it won't
is unsafe. It is best to explicitly NULL the return pointer if file_init_path()
returns a failure.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The current behaviour of --bmc is to take over the flash controller. This
flag was written for very early bring-up when the BMC stack would run
entirely out of RAM. This is no longer the case and using --bmc on a BMC
running out of the very flash --bmc will read is extremely likely to brick
the system.
It has come to light that there is some requirement to read BMC flash and
some thinking that pflash is the appropriate tool. As AMI BMC firmware
exposes the flash through /dev/mtd and pflash can be easily taught to read
from MTD pflash can be upgraded to be the tool for the job.
In order to preserve the current behavior of the --bmc a new flag --mtd
has been introduced to have pflash access BMC flash the 'safe' way.
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>
|
|
pnor.c existed before blocklevel, it is time that this code got updated to
use the available libraries.
Changes include using the blocklevel accessors for MTD reads and writes
rather than read() and write() on a file descriptor.
This patch also makes use of the arch_flash_init() auto detection of the
/dev/mtd device which corresponds to the MTD device exposed by skiboot for
access to platform flash.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
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>
|
|
|
|
Signed-off-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
When building under buildroot, libflash was being built before the
links:
make[2]: *** No rule to make target 'libflash/libflash.c', needed by
'libflash-libflash.o'. Stop.
make[2]: *** Waiting for unfinished jobs....
LN ccan
LN common
LN libflash
To reproduce this outside of buildroot, set PFLASH_VERSION to anything.
This is another race that is only exposed in certain conditions. By
describing the dependencies on the source files the build works again.
I think it's almost time to stop using symlinks.
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>
|
|
Adding quiet rules to make our output a bit cleaner. Building now looks
like this:
$ make
LN libflash
LN common
LN ccan
CC pflash.o
CC version.o
LD common-arch_flash.o
CC pflash
You can see the full build ouput by doing a "make V=1".
By doing this, we build fractionally faster, exposing arace condition
between running the make_version.sh script and the link existing for it.
As we run it when creating the variable, there is no way to ensure it
exists first.
Solved this by not creating the symlink and simply running
make_version.sh from the root.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
pflash contained a copy of the include/ast.h header. It had grown stale,
so remove in and link in the common header.
Note that it's hard to test that we haven't broken tools in the
external/ directory these days; when making changes we need to test with
amd64, ppc64, ppc64le and arm to ensure that everything can build!
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In order to be able to compile for something that isn't the default for the
compiler one should be able to use CFLAGS and LDFLAGS on commandline.
ie build a 64bit binary with a compiler which builds by default 32bit or
the opposite endian for which the compiler is configured.
Currently the common/rules.mk ignores LDFLAGS when it shouldn't and pflash
sets LDFLAGS for something which only applies to the final link.
This patch addresses both those issues.
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>
Reviewed-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Reviewed-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
It would be nice if tools like the gard tool or pflash don't have to worry
about how to build the arch specific code they want to include through the
new external/common code.
This patch adds an external/common/rules.mk which each tool can include and
with some minor tweaking of the existing makefiles it should get the arch
code building nicely.
The one caveat is that it requires a symlink in the directory to create
common/ dir for everything to behave.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This allows for manipulation of flash image files on an x86 system before
flashing. This may prove useful for development.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
As per commit to create the external/common code, this commit introduces
the POWER arch compatibility flash reading code.
This commit actually should cause no functional change to pflash (it won't
be able to access the BMC flash if it ever could), however rather than
accessing the flash via the debugfs opal_lpc_{read,write} interface it will
access it though the MTD interface provided by linux and importantly skiboot.
Not only does using the MTD interface allows applications to treat it like
flash despite the fact that they are talking through several layers of
abstraction. Using passing through skiboot means that all the access to the
flash from the Power8 can be protected from concurrent access.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Previous work did away with some typesafety when adding the
blocklevel_device abstraction, this has resulted in the ability to
accidently call libflash low level code with a blocklevel_device which has
not been initialised by the libflash backend.
The end result will not be good. Best to reintroduce that low level calls
be called with libflashes own structures.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In order to access the flash on ARM (presumably code running on a BMC), the
hardware is involved. In order to access the flash on POWER (presumably
code running on a host), opal calls through the Linux MTD driver are
involved. In order to access the flash on x86 (presumably on a
developer/admin system), you can't but it would be nice to be able to
manipulate data which has come from the flash or will go onto the flash.
The pflash and the gard tool both can read and write to the 'flash' and
with the introduction of the blocklevel interface the details of how the
flash is read from and written to is sufficiently abstracted that these
tools don't need to know what they're running on.
What does differ is the setup, and not by too much either. This common code
pulls out the setup of the flash hardware on ARM, the searching for the
appropriate MTD device on power and generic blocklevel device init for all
three architectures.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|