| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
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>
|
|
libflash/file.c: In function 'file_erase':
libflash/file.c:134:1: error: the frame size of 4128 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
}
^
and
ffspart.c: In function ‘main’:
ffspart.c:529:1: error: the frame size of 4864 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
}
^
In both cases, mark the local variables as static to avoid the stack.
The static approach is valid for file.c as the buffer is always filled
with `~0`. Given it's now going to be in .bss due to static we have to
still perform the memset(), but racing memset()s in this fashion won't
be harmful, just wasteful.
For ffspart.c's main(), there are bigger problems if that needs to be
re-entrant.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Do 4096 byte chunks not 8 byte chunks. A ffspart invocation constructing
a 64MB PNOR goes from a couple of seconds to ~0.1seconds with this
patch.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
Reviewed-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Stewart Smith <stewart@linux.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>
|
|
Unfortunately not all drivers are created equal and several drivers on
which pflash relies block in the kernel for quite some time and ignore
signals.
This is really only a problem if pflash is to perform large erases. So
don't, perform these ops in small chunks.
An in kernel fix is possible in most cases but it takes time and systems
will be running older drivers for quite some time. Since sector erases
aren't significantly slower than whole chip erases there isn't much of a
performance penalty to breaking up the erase ioctl()s.
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>
|
|
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>
|
|
We recently made MTD 64 bit safe in e5720d3fe94 which now requires the
64 bit MTD erase ioctl. Unfortunately this ioctl is not present in
older kernels used by some BMC vendors that use pflash.
This patch addresses this by only using the 64bit version of the erase
ioctl() if the parameters exceed 32bit in size.
If an erase requires the 64bit ioctl() on a kernel which does not
support it, the code will still attempt it. There is no way of knowing
beforehand if the kernel supports it. The ioctl() will fail and an error
will be returned from from the function.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Michael Neuling <mikey@neuling.org>
|
|
While we'll 'never' have flash chips larger than 32bit, work was
recently done to blocklevel for it to be 64bit compatible for other
backends.
Since there is a 64bit ioctl() lets use it. There is currently no known
case where 32bit is not sufficient but this doesn't mean someone might
not do something strange in the future.
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>
|
|
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>
|
|
If we had a truncated file where libflash would attempt to read past
the end, instead of erroring out, we'd get stuck in an infinite loop.
Why? Because we weren't acknowledging that read() returns 0 on EOF.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Reviewed-by: Cyril Bur <cyril.bur@au1.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>
Reviewed-by: Cyril Bur <cyrilbur@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Currently libflash reads from files by using the dodgy file_flash.c which
implements a very flash hardware themed interface but subverts it to read,
write and erase from a file descriptor.
With the introduction of this file backend, this will no longer be needed.
Reviewed-By: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
