<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/arch/mips/cpu, branch v2017.01</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>MIPS: add possibility to setup initial stack and global data in SRAM</title>
<updated>2016-11-30T15:11:46+00:00</updated>
<author>
<name>Daniel Schwierzeck</name>
<email>daniel.schwierzeck@gmail.com</email>
</author>
<published>2016-06-04T14:13:21+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=924ad86638705fe37db98812f355260669f0f043'/>
<id>924ad86638705fe37db98812f355260669f0f043</id>
<content type='text'>
This adds a new Kconfig option CONFIG_MIPS_INIT_STACK_IN_SRAM which
a SoC can select if it supports some kind of SRAM. Together with
CONFIG_SYS_INIT_SP_ADDR the initial stack and global data can be
set up in that SRAM. This can be used to provide a C environment
also for lowlevel_init().

Signed-off-by: Daniel Schwierzeck &lt;daniel.schwierzeck@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This adds a new Kconfig option CONFIG_MIPS_INIT_STACK_IN_SRAM which
a SoC can select if it supports some kind of SRAM. Together with
CONFIG_SYS_INIT_SP_ADDR the initial stack and global data can be
set up in that SRAM. This can be used to provide a C environment
also for lowlevel_init().

Signed-off-by: Daniel Schwierzeck &lt;daniel.schwierzeck@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: factor out code for initial stack and global data</title>
<updated>2016-11-30T15:11:46+00:00</updated>
<author>
<name>Daniel Schwierzeck</name>
<email>daniel.schwierzeck@gmail.com</email>
</author>
<published>2016-09-25T16:36:38+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=c3e72ab80135a19ac6eb2585b69de0acf19b87c1'/>
<id>c3e72ab80135a19ac6eb2585b69de0acf19b87c1</id>
<content type='text'>
Move the code for setting up the initial stack and global data
to a macro to be able to use it more than once.

Signed-off-by: Daniel Schwierzeck &lt;daniel.schwierzeck@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Move the code for setting up the initial stack and global data
to a macro to be able to use it more than once.

Signed-off-by: Daniel Schwierzeck &lt;daniel.schwierzeck@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: fix iand optimize setup of CP0 registers</title>
<updated>2016-11-30T15:11:46+00:00</updated>
<author>
<name>Daniel Schwierzeck</name>
<email>daniel.schwierzeck@gmail.com</email>
</author>
<published>2016-02-07T23:37:59+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=65d297af7c6a08ec65bf005fa9bd5cdb955efe39'/>
<id>65d297af7c6a08ec65bf005fa9bd5cdb955efe39</id>
<content type='text'>
Clear cp0 status while preserving implementation specific bits.
Set bits BEV and ERL as the arch specification requires after
a reset or soft-reset exception.

Extend and fix initialization of watch registers. Check if additional
watch register sets are implemented and initialize them too.

Initialize cp0 count as early as possible to get the most
accurate boot timing.

Signed-off-by: Daniel Schwierzeck &lt;daniel.schwierzeck@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Clear cp0 status while preserving implementation specific bits.
Set bits BEV and ERL as the arch specification requires after
a reset or soft-reset exception.

Extend and fix initialization of watch registers. Check if additional
watch register sets are implemented and initialize them too.

Initialize cp0 count as early as possible to get the most
accurate boot timing.

Signed-off-by: Daniel Schwierzeck &lt;daniel.schwierzeck@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: fix ROM exception vectors</title>
<updated>2016-11-30T15:11:39+00:00</updated>
<author>
<name>Daniel Schwierzeck</name>
<email>daniel.schwierzeck@gmail.com</email>
</author>
<published>2016-02-07T18:39:58+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=345490fcd68d830adef7fcfa4ef5bf5681c29546'/>
<id>345490fcd68d830adef7fcfa4ef5bf5681c29546</id>
<content type='text'>
When booting from ROM, early exceptions can't be handled
properly. Instead of busy-looping give the developer the
possibilty to examine the situation. Invoke an UHI
exception operation which can be read as unhandled exception
by a hardware debugger if one is attached. If the debugger
doesn't support UHI, the exception is read as unexpected
breakpoint.

Signed-off-by: Daniel Schwierzeck &lt;daniel.schwierzeck@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When booting from ROM, early exceptions can't be handled
properly. Instead of busy-looping give the developer the
possibilty to examine the situation. Invoke an UHI
exception operation which can be read as unhandled exception
by a hardware debugger if one is attached. If the debugger
doesn't support UHI, the exception is read as unexpected
breakpoint.

Signed-off-by: Daniel Schwierzeck &lt;daniel.schwierzeck@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: make inclusion of ROM exception vectors configurable</title>
<updated>2016-11-30T15:07:17+00:00</updated>
<author>
<name>Daniel Schwierzeck</name>
<email>daniel.schwierzeck@gmail.com</email>
</author>
<published>2016-02-14T17:52:57+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=af3971f81ac0fc344461cf86af682ecf1ebe18a8'/>
<id>af3971f81ac0fc344461cf86af682ecf1ebe18a8</id>
<content type='text'>
This adds a compile time option to include code for static
exception vectors. Static exception vectors are only needed,
when the U-Boot entry point is equal to the CPU reset exception
vector address. For instance this is the case when U-Boot is
used as ROM in Qemu or booted from parallel NOR flash. When
U-Boot is booted from RAM (e.g. loaded there by SPL), the
exception vectors need to be setup dynamically, which is done
in follow-up commits.

Signed-off-by: Daniel Schwierzeck &lt;daniel.schwierzeck@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This adds a compile time option to include code for static
exception vectors. Static exception vectors are only needed,
when the U-Boot entry point is equal to the CPU reset exception
vector address. For instance this is the case when U-Boot is
used as ROM in Qemu or booted from parallel NOR flash. When
U-Boot is booted from RAM (e.g. loaded there by SPL), the
exception vectors need to be setup dynamically, which is done
in follow-up commits.

Signed-off-by: Daniel Schwierzeck &lt;daniel.schwierzeck@gmail.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>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>
<entry>
<title>MIPS: Map CM Global Control Registers</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:53+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=b2b135d980a7171c9b0eefbb38861ccbe9a47f97'/>
<id>b2b135d980a7171c9b0eefbb38861ccbe9a47f97</id>
<content type='text'>
Map the Global Control Registers (GCRs) provided by the MIPS Coherence
Manager (CM) in preparation for using some of them in later patches.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Map the Global Control Registers (GCRs) provided by the MIPS Coherence
Manager (CM) in preparation for using some of them in later patches.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: If we don't need DDR for cache init, init cache first</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:51+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=f8981277f581564bf701d310fe0f68903cf3f542'/>
<id>f8981277f581564bf701d310fe0f68903cf3f542</id>
<content type='text'>
On systems where cache initialisation doesn't require zeroed memory (ie.
systems where CONFIG_SYS_MIPS_CACHE_INIT_RAM_LOAD is not defined)
perform cache initialisation prior to lowlevel_init &amp; DDR
initialisation. This allows for DDR initialisation code to run cached &amp;
thus significantly faster.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On systems where cache initialisation doesn't require zeroed memory (ie.
systems where CONFIG_SYS_MIPS_CACHE_INIT_RAM_LOAD is not defined)
perform cache initialisation prior to lowlevel_init &amp; DDR
initialisation. This allows for DDR initialisation code to run cached &amp;
thus significantly faster.

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