<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/arch/mips, branch v2016.11</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>Fix spelling of "resetting".</title>
<updated>2016-10-31T14:13:17+00:00</updated>
<author>
<name>Vagrant Cascadian</name>
<email>vagrant@debian.org</email>
</author>
<published>2016-10-24T03:45:19+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=3450a8596d3c06107ccf44d2ad41402449e681dd'/>
<id>3450a8596d3c06107ccf44d2ad41402449e681dd</id>
<content type='text'>
Cover-Letter: Fixes several spelling errors for the words "resetting",
  "extended", "occur", and "multiple".

Signed-off-by: Vagrant Cascadian &lt;vagrant@debian.org&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Cover-Letter: Fixes several spelling errors for the words "resetting",
  "extended", "occur", and "multiple".

Signed-off-by: Vagrant Cascadian &lt;vagrant@debian.org&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi: Use asmlinkage for EFIAPI</title>
<updated>2016-10-19T07:01:53+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2016-09-25T21:27:31+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=a0b49bc3341f8f19cbf57a56d110ab0fa8f39267'/>
<id>a0b49bc3341f8f19cbf57a56d110ab0fa8f39267</id>
<content type='text'>
This is required for x86 and is also correct for ARM (since it is empty).

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is required for x86 and is also correct for ARM (since it is empty).

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
Signed-off-by: Alexander Graf &lt;agraf@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Remove arch/${ARCH}/include/asm/errno.h</title>
<updated>2016-09-23T21:56:18+00:00</updated>
<author>
<name>Masahiro Yamada</name>
<email>yamada.masahiro@socionext.com</email>
</author>
<published>2016-09-21T02:28:56+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=4491327d59179a212e36f1889bd143c99159138b'/>
<id>4491327d59179a212e36f1889bd143c99159138b</id>
<content type='text'>
Unlike Linux, nothing about errno.h is arch-specific in U-Boot.
As you see, all of arch/${ARCH}/include/asm/errno.h is just a
wrapper of &lt;asm-generic/errno.h&gt;.  Actually, U-Boot does not
export headers to user-space, so we just have to care about the
consistency in the U-Boot tree.

Now all of include directives for &lt;asm/errno.h&gt; are gone.
Deprecate &lt;asm/errno.h&gt;.

Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Acked-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Unlike Linux, nothing about errno.h is arch-specific in U-Boot.
As you see, all of arch/${ARCH}/include/asm/errno.h is just a
wrapper of &lt;asm-generic/errno.h&gt;.  Actually, U-Boot does not
export headers to user-space, so we just have to care about the
consistency in the U-Boot tree.

Now all of include directives for &lt;asm/errno.h&gt; are gone.
Deprecate &lt;asm/errno.h&gt;.

Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Acked-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>treewide: replace #include &lt;asm/errno.h&gt; with &lt;linux/errno.h&gt;</title>
<updated>2016-09-23T21:55:42+00:00</updated>
<author>
<name>Masahiro Yamada</name>
<email>yamada.masahiro@socionext.com</email>
</author>
<published>2016-09-21T02:28:55+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=1221ce459d04a428f8880f58581f671b736c3c27'/>
<id>1221ce459d04a428f8880f58581f671b736c3c27</id>
<content type='text'>
Now, arch/${ARCH}/include/asm/errno.h and include/linux/errno.h have
the same content.  (both just wrap &lt;asm-generic/errno.h&gt;)

Replace all include directives for &lt;asm/errno.h&gt; with &lt;linux/errno.h&gt;.

Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
[trini: Fixup include/clk.]
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Now, arch/${ARCH}/include/asm/errno.h and include/linux/errno.h have
the same content.  (both just wrap &lt;asm-generic/errno.h&gt;)

Replace all include directives for &lt;asm/errno.h&gt; with &lt;linux/errno.h&gt;.

Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
[trini: Fixup include/clk.]
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Hang if run on a secondary CPU</title>
<updated>2016-09-21T15:04:53+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@imgtec.com</email>
</author>
<published>2016-09-21T13:59:54+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=31d36f748c52b22833aa946f6c406cc8fb2f1908'/>
<id>31d36f748c52b22833aa946f6c406cc8fb2f1908</id>
<content type='text'>
Some systems are configured such that multiple CPUs begin running from
their reset vector following a system reset. If this occurs then U-Boot
will be run on multiple CPUs simultaneously, which causes all sorts of
issues as the multiple instances of U-Boot clobber each other.

Prevent this from happening by simply hanging with an infinite loop if
we run on a CPU whose ID, as determined by GlobalNumber or EBase.CPUNum
as appropriate, is non-zero.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some systems are configured such that multiple CPUs begin running from
their reset vector following a system reset. If this occurs then U-Boot
will be run on multiple CPUs simultaneously, which causes all sorts of
issues as the multiple instances of U-Boot clobber each other.

Prevent this from happening by simply hanging with an infinite loop if
we run on a CPU whose ID, as determined by GlobalNumber or EBase.CPUNum
as appropriate, is non-zero.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Fix cache maintenance in relocate_code &amp; simplify</title>
<updated>2016-09-21T14:25:43+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@imgtec.com</email>
</author>
<published>2016-09-21T10:11:06+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d263cda5ae41279208d9576eab1c5215a57252a6'/>
<id>d263cda5ae41279208d9576eab1c5215a57252a6</id>
<content type='text'>
The relocate_code function was handling cache maintenance incorrectly.
It copied U-Boot to its new location, flushed the caches &amp; then
proceeded to apply relocations &amp; jump to the new code without flushing
the caches again. This is problematic as the instruction cache could
potentially have already fetched instructions that hadn't had relocs
applied.

Rework this to perform the flush_cache call using the code in the
original copy of U-Boot, after having applied relocations to the new
copy of U-Boot. The new U-Boot can then be jumped to safely once that
cache flush has been performed.

As part of this, since the old U-Boot is used up until after that cache
flush, complexity around loading values from the GOT using a jump &amp; link
instruction &amp; loads from a table is removed. Instead we can simply load
the needed values with PTR_LA fromt the original GOT.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The relocate_code function was handling cache maintenance incorrectly.
It copied U-Boot to its new location, flushed the caches &amp; then
proceeded to apply relocations &amp; jump to the new code without flushing
the caches again. This is problematic as the instruction cache could
potentially have already fetched instructions that hadn't had relocs
applied.

Rework this to perform the flush_cache call using the code in the
original copy of U-Boot, after having applied relocations to the new
copy of U-Boot. The new U-Boot can then be jumped to safely once that
cache flush has been performed.

As part of this, since the old U-Boot is used up until after that cache
flush, complexity around loading values from the GOT using a jump &amp; link
instruction &amp; loads from a table is removed. Instead we can simply load
the needed values with PTR_LA fromt the original GOT.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>boston: Introduce support for the MIPS Boston development board</title>
<updated>2016-09-21T14:24:36+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@imgtec.com</email>
</author>
<published>2016-09-08T06:47:39+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=ad8783cb1cb258b71d81800f72cd64eb44081653'/>
<id>ad8783cb1cb258b71d81800f72cd64eb44081653</id>
<content type='text'>
This patch introduces support for building U-Boot to run on the MIPS
Boston development board. This is a board built around an FPGA &amp; an
Intel EG20T Platform Controller Hub, used largely as part of the
development of new CPUs and their software support. It is essentially
the successor to the older MIPS Malta board.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch introduces support for building U-Boot to run on the MIPS
Boston development board. This is a board built around an FPGA &amp; an
Intel EG20T Platform Controller Hub, used largely as part of the
development of new CPUs and their software support. It is essentially
the successor to the older MIPS Malta board.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Ensure cache ops complete in mips_cache_reset</title>
<updated>2016-09-21T13:04:04+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@imgtec.com</email>
</author>
<published>2016-09-21T10:18:59+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=639200f6a0dcfe67e4c923b6108703e192946388'/>
<id>639200f6a0dcfe67e4c923b6108703e192946388</id>
<content type='text'>
Ensure that cache operations complete before returning from
mips_cache_reset by placing a completion barrier (sync instruction)
before the return. Without this there is no guarantee that the cache ops
will complete before any subsequent memory accesses, since they are
indexed cache ops &amp; thus not implicitly ordered with memory accesses.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Ensure that cache operations complete before returning from
mips_cache_reset by placing a completion barrier (sync instruction)
before the return. Without this there is no guarantee that the cache ops
will complete before any subsequent memory accesses, since they are
indexed cache ops &amp; thus not implicitly ordered with memory accesses.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Clear hazard between TagLo writes &amp; cache ops</title>
<updated>2016-09-21T13:04:04+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@imgtec.com</email>
</author>
<published>2016-09-21T10:18:58+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d608254b0aa23607df1dcb5a7ca07de9a8ec9bb0'/>
<id>d608254b0aa23607df1dcb5a7ca07de9a8ec9bb0</id>
<content type='text'>
Writing to the coprocessor 0 TagLo registers introduces an execution
hazard in that we need that write to complete before any cache
instructions execute. Ensure that hazard is cleared by inserting an ehb
instruction between the TagLo writes &amp; cache op loop.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Writing to the coprocessor 0 TagLo registers introduces an execution
hazard in that we need that write to complete before any cache
instructions execute. Ensure that hazard is cleared by inserting an ehb
instruction between the TagLo writes &amp; cache op loop.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Ensure Config.K0=2 applies before any memory accesses</title>
<updated>2016-09-21T13:04:04+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@imgtec.com</email>
</author>
<published>2016-09-21T10:18:57+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=c5b8412d60e22b49348a63848cbf7b6ab5ccb16e'/>
<id>c5b8412d60e22b49348a63848cbf7b6ab5ccb16e</id>
<content type='text'>
During boot we set Config.K0=2 (uncached) such that any accesses to the
kseg0 memory region are performed uncached before the caches are
initialised. This write to the Config register introduces an execution
hazard between it &amp; any following memory accesses (such as the load of
_gp), which we need to clear in order to ensure those memory accesses
are actually performed uncached. Clear this execution hazard with the
insertion of an ehb execution hazard barrier instruction.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
During boot we set Config.K0=2 (uncached) such that any accesses to the
kseg0 memory region are performed uncached before the caches are
initialised. This write to the Config register introduces an execution
hazard between it &amp; any following memory accesses (such as the load of
_gp), which we need to clear in order to ensure those memory accesses
are actually performed uncached. Clear this execution hazard with the
insertion of an ehb execution hazard barrier instruction.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
