<feed xmlns='http://www.w3.org/2005/Atom'>
<title>talos-skiboot/libc/string/Makefile.inc, branch master</title>
<subtitle>Talos™ II skiboot sources</subtitle>
<id>https://git.raptorcs.com/git/talos-skiboot/atom?h=master</id>
<link rel='self' href='https://git.raptorcs.com/git/talos-skiboot/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-skiboot/'/>
<updated>2018-03-01T02:28:39+00:00</updated>
<entry>
<title>build: use thin archives rather than incremental linking</title>
<updated>2018-03-01T02:28:39+00:00</updated>
<author>
<name>Nicholas Piggin</name>
<email>npiggin@gmail.com</email>
</author>
<published>2018-02-10T08:42:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-skiboot/commit/?id=f6159cff5d91e5c0810d0c9285a1d2370a38e2b7'/>
<id>urn:sha1:f6159cff5d91e5c0810d0c9285a1d2370a38e2b7</id>
<content type='text'>
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 &lt;npiggin@gmail.com&gt;
Signed-off-by: Stewart Smith &lt;stewart@linux.vnet.ibm.com&gt;
</content>
</entry>
<entry>
<title>libc/string: add memcpy_from_ci()</title>
<updated>2016-10-05T03:42:26+00:00</updated>
<author>
<name>Claudio Carvalho</name>
<email>cclaudio@linux.vnet.ibm.com</email>
</author>
<published>2016-09-28T08:01:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-skiboot/commit/?id=26a1d0c487d6b61afb0a338189d98c91bb481ee9'/>
<id>urn:sha1:26a1d0c487d6b61afb0a338189d98c91bb481ee9</id>
<content type='text'>
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 &lt;cclaudio@linux.vnet.ibm.com&gt;
Signed-off-by: Stewart Smith &lt;stewart@linux.vnet.ibm.com&gt;
</content>
</entry>
<entry>
<title>Initial commit of Open Source release</title>
<updated>2014-07-02T05:36:20+00:00</updated>
<author>
<name>Benjamin Herrenschmidt</name>
<email>benh@kernel.crashing.org</email>
</author>
<published>2014-07-02T05:36:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-skiboot/commit/?id=1d880992fd8c8457a2d990ac6622cfd58fb1b261'/>
<id>urn:sha1:1d880992fd8c8457a2d990ac6622cfd58fb1b261</id>
<content type='text'>
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</content>
</entry>
</feed>
