Age | Commit message (Collapse) | Author | Files | Lines |
|
Sometimes handy.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
int to size_t
Reason of the change as integer value may overflow, and it can give negative
value for the length.
This patch also changes the data type of variable which is compared with
strlen() as the comparison also has to be done on the same level.
Signed-off-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This adds memcpy_from_ci, a cache inhibited version of memcpy, required
by secure boot. The secure boot verification code is stored in a secure
ROM and the logic that contains the ROM within the processor is
implemented in a way that it only responds to CI (cache inhibited)
operations. Due to performance issues we copy the verification code from
the secure ROM to RAM and we use memcpy_ci for that.
What makes memcpy_ci vs ordinary memcpy?
memcpy copies data like in the example below and the compiler translates that
to load instructions that are not cache inhibited (e.g. lbzx - load byte and
zero indexed). In other words, the data is cached.
a[i] = b[i]
memcpy_ci copies data using the cache inhibited version of load instructions:
in_8() and in_be32(), both defined in include/io.h. These functions use lbzcix
and lwzcix assembly instructions, respectively. In this case, the data is not
cached as required by the logic that contains the ROM.
*((uint8_t*) destp) = in_8((uint8_t*)srcp);
*((uint32_t*) destp) = in_be32((uint32_t*)srcp)
Signed-off-by: Claudio Carvalho <cclaudio@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Reviewed-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
|
|
Memory poisoning hammers this, so let's be a bit smart about it and
avoid falling back to byte stores when the data is not 0
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This uses the dcbz instruction to clear cacheline at a time rather than
byte at a time. This means that even without high levels of optimization,
we *dramatically* improve boot performance with SKIBOOT_GCOV=1 and probably
ever so slightly speed things up for normal builds.
We currently just hard-code 128 as cacheline size as all CPUs that skiboot
currently boots on have 128 byte cachelines.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|