<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/arch/arc/lib, branch v2016.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>arc: significant cache rework</title>
<updated>2015-07-01T14:17:27+00:00</updated>
<author>
<name>Alexey Brodkin</name>
<email>Alexey.Brodkin@synopsys.com</email>
</author>
<published>2015-05-18T13:56:26+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=ef639e6f7076c19959f40f367cead5108d099592'/>
<id>ef639e6f7076c19959f40f367cead5108d099592</id>
<content type='text'>
[1] Align cache management functions to those in Linux kernel. I.e.:
    a) Use the same functions for all cache ops (D$ Inv/Flush)
    b) Split cache ops in 3 sub-functions: "before", "lineloop" and
"after". That way we may re-use "before" and "after" functions for
region and full cache ops.

 [2] Implement full-functional L2 (SLC) management. Before SLC was
simply disabled early on boot. It's also possible to enable or disable
L2 cache from config utility.

 [3] Disable/enable corresponding caches early on boot. So if U-Boot is
configured to use caches they will be used at all times (this is useful
in partucular for speed-up of relocation).

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[1] Align cache management functions to those in Linux kernel. I.e.:
    a) Use the same functions for all cache ops (D$ Inv/Flush)
    b) Split cache ops in 3 sub-functions: "before", "lineloop" and
"after". That way we may re-use "before" and "after" functions for
region and full cache ops.

 [2] Implement full-functional L2 (SLC) management. Before SLC was
simply disabled early on boot. It's also possible to enable or disable
L2 cache from config utility.

 [3] Disable/enable corresponding caches early on boot. So if U-Boot is
configured to use caches they will be used at all times (this is useful
in partucular for speed-up of relocation).

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arc: implement slave cores kick-start for Linux kernel</title>
<updated>2015-07-01T14:17:27+00:00</updated>
<author>
<name>Alexey Brodkin</name>
<email>abrodkin@synopsys.com</email>
</author>
<published>2015-04-13T10:37:05+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=8b2eb776b13055e71f94367c06a26c5e3a902f16'/>
<id>8b2eb776b13055e71f94367c06a26c5e3a902f16</id>
<content type='text'>
With new SMP-enabled CPUs with ARC HS38 cores and corresponding support
in Linux kernel it's required to add basic SMP support in U-Boot.

Currently we assume the one and only core starts execution after
power-on. So most of things in U-Boot is handled in UP mode.

But when U-Boot is used for loading and starting Linux kernel right
before jumping to kernel's entry point U-Boot:
 [1] Sets all slave cores to jump to the same address [kernel's entry
point]
 [2] Really starts all slav cores

In ARC's implemetation of SMP in Linux kernel all cores are supposed to
run the same start-up code. But only core with ID 0 (master core)
processes further while others are looping waiting for master core to
complete some initialization.

That means it's safe to un-pause slave cores and let them execute kernel
- they will wait for master anyway.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
Cc: Vineet Gupta &lt;vgupta@synopsys.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With new SMP-enabled CPUs with ARC HS38 cores and corresponding support
in Linux kernel it's required to add basic SMP support in U-Boot.

Currently we assume the one and only core starts execution after
power-on. So most of things in U-Boot is handled in UP mode.

But when U-Boot is used for loading and starting Linux kernel right
before jumping to kernel's entry point U-Boot:
 [1] Sets all slave cores to jump to the same address [kernel's entry
point]
 [2] Really starts all slav cores

In ARC's implemetation of SMP in Linux kernel all cores are supposed to
run the same start-up code. But only core with ID 0 (master core)
processes further while others are looping waiting for master core to
complete some initialization.

That means it's safe to un-pause slave cores and let them execute kernel
- they will wait for master anyway.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
Cc: Vineet Gupta &lt;vgupta@synopsys.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arc: fix separate compilation of start.o</title>
<updated>2015-04-10T16:22:40+00:00</updated>
<author>
<name>Alexey Brodkin</name>
<email>abrodkin@synopsys.com</email>
</author>
<published>2015-04-10T16:22:40+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=a811492e4f386f79b122b210ac8e66915c27f767'/>
<id>a811492e4f386f79b122b210ac8e66915c27f767</id>
<content type='text'>
While testing "arc: make sure _start is in the beginning of .text
section" I haven't done proper clean-up of built binaries and so missed
another tiny bit that lead to the following error:
 ---&gt;8---
    LD      u-boot
 arc-linux-ld.bfd: cannot find arch/arc/lib/start.o
 Makefile:1107: recipe for target 'u-boot' failed
 make: *** [u-boot] Error 1
 ---&gt;8---

Fix is trivial: put "start.o" in "extra-y".

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
While testing "arc: make sure _start is in the beginning of .text
section" I haven't done proper clean-up of built binaries and so missed
another tiny bit that lead to the following error:
 ---&gt;8---
    LD      u-boot
 arc-linux-ld.bfd: cannot find arch/arc/lib/start.o
 Makefile:1107: recipe for target 'u-boot' failed
 make: *** [u-boot] Error 1
 ---&gt;8---

Fix is trivial: put "start.o" in "extra-y".

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>arc: make sure _start is in the beginning of .text section</title>
<updated>2015-04-10T15:45:34+00:00</updated>
<author>
<name>Alexey Brodkin</name>
<email>abrodkin@synopsys.com</email>
</author>
<published>2015-04-10T15:41:58+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=89576072cb60d50b61813f901c6fc296c01de506'/>
<id>89576072cb60d50b61813f901c6fc296c01de506</id>
<content type='text'>
This is important to have entry point in the beginning of .text section
because it allows simple loading and execution of U-Boot.

For example pre-bootloader loads U-Boot in memory starting from offset
0x81000000 and then just jumps to the same address.

Otherwise pre-bootloader would need to find-out where entry-point is. In
its turn if it deals with binary image of U-Boot there's no way for
pre-bootloader to get required value.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is important to have entry point in the beginning of .text section
because it allows simple loading and execution of U-Boot.

For example pre-bootloader loads U-Boot in memory starting from offset
0x81000000 and then just jumps to the same address.

Otherwise pre-bootloader would need to find-out where entry-point is. In
its turn if it deals with binary image of U-Boot there's no way for
pre-bootloader to get required value.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arc: add support for SLC (System Level Cache, AKA L2-cache)</title>
<updated>2015-04-03T06:47:50+00:00</updated>
<author>
<name>Alexey Brodkin</name>
<email>abrodkin@synopsys.com</email>
</author>
<published>2015-03-30T10:36:04+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=6eb15e50f48927c65a67371555b5afc24b3c7d21'/>
<id>6eb15e50f48927c65a67371555b5afc24b3c7d21</id>
<content type='text'>
ARCv2 cores may have built-in SLC (System Level Cache, AKA L2-cache).
This change adds functions required for controlling SLC:
 * slc_enable/disable
 * slc_flush/invalidate

For now we just disable SLC to escape DMA coherency issues until either:
 * SLC flush/invalidate is supported in DMA APIin U-Boot
 * hardware DMA coherency is implemented (that might be board specific
   so probably we'll need to have a separate Kconfig option for
   controlling SLC explicitly)

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ARCv2 cores may have built-in SLC (System Level Cache, AKA L2-cache).
This change adds functions required for controlling SLC:
 * slc_enable/disable
 * slc_flush/invalidate

For now we just disable SLC to escape DMA coherency issues until either:
 * SLC flush/invalidate is supported in DMA APIin U-Boot
 * hardware DMA coherency is implemented (that might be board specific
   so probably we'll need to have a separate Kconfig option for
   controlling SLC explicitly)

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>arc: get rid of CONFIG_SYS_GENERIC_GLOBAL_DATA</title>
<updated>2015-04-03T06:47:49+00:00</updated>
<author>
<name>Alexey Brodkin</name>
<email>abrodkin@synopsys.com</email>
</author>
<published>2015-02-25T15:10:18+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=f56d625ee07a1ffb424e6c9278dd84b534e0bc1e'/>
<id>f56d625ee07a1ffb424e6c9278dd84b534e0bc1e</id>
<content type='text'>
As discussed on mailing list we're drifting away from
CONFIG_SYS_GENERIC_GLOBAL_DATA in favour to use of board_init_f_mem()
for global data.

So do this for ARC architecture.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As discussed on mailing list we're drifting away from
CONFIG_SYS_GENERIC_GLOBAL_DATA in favour to use of board_init_f_mem()
for global data.

So do this for ARC architecture.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arc: clean-up init procedure</title>
<updated>2015-04-03T06:47:49+00:00</updated>
<author>
<name>Alexey Brodkin</name>
<email>abrodkin@synopsys.com</email>
</author>
<published>2015-02-24T16:40:36+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=3fb8016360d5433f3c4da51f8dd57550e7ef9018'/>
<id>3fb8016360d5433f3c4da51f8dd57550e7ef9018</id>
<content type='text'>
Intention behind this work was elimination of as much assembly-written
code as it is possible.

In case of ARC we already have relocation fix-up implemented in C so why
don't we use C for U-Boot copying, .bss zeroing etc.

It turned out x86 uses pretty similar approach so we re-used parts of
code in "board_f.c" initially implemented for x86.

Now assembly usage during init is limited to stack- and frame-pointer
setup before and after relocation.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
Cc: Simon Glass &lt;sjg@chromium.org&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Intention behind this work was elimination of as much assembly-written
code as it is possible.

In case of ARC we already have relocation fix-up implemented in C so why
don't we use C for U-Boot copying, .bss zeroing etc.

It turned out x86 uses pretty similar approach so we re-used parts of
code in "board_f.c" initially implemented for x86.

Now assembly usage during init is limited to stack- and frame-pointer
setup before and after relocation.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
Cc: Simon Glass &lt;sjg@chromium.org&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>arc: move low-level interrupt and exception handlers in a separate file</title>
<updated>2015-04-03T06:47:49+00:00</updated>
<author>
<name>Alexey Brodkin</name>
<email>abrodkin@synopsys.com</email>
</author>
<published>2015-02-24T14:08:44+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=8ee28251d95e237302c7c44929e59a813e147622'/>
<id>8ee28251d95e237302c7c44929e59a813e147622</id>
<content type='text'>
This separation makes maintenance of code easier because those low-level
interrupt- or exception handling routines are pretty static and usually
require not much care while start-up code is a subject of modifications
and enhancements.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This separation makes maintenance of code easier because those low-level
interrupt- or exception handling routines are pretty static and usually
require not much care while start-up code is a subject of modifications
and enhancements.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>arc: merge common start-up code between ARC and ARCv2</title>
<updated>2015-04-03T06:47:49+00:00</updated>
<author>
<name>Alexey Brodkin</name>
<email>abrodkin@synopsys.com</email>
</author>
<published>2015-02-19T15:40:58+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=4d93617d87285f01f450a30584520369ff3585d2'/>
<id>4d93617d87285f01f450a30584520369ff3585d2</id>
<content type='text'>
Even though ARCompact and ARCv2 are not binary compatible most of
assembly instructions are used in both. With this change we'll get rid
of duplicate code.

Still IVTs are implemented differently so we're keeping them in separate
files.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Even though ARCompact and ARCv2 are not binary compatible most of
assembly instructions are used in both. With this change we'll get rid
of duplicate code.

Still IVTs are implemented differently so we're keeping them in separate
files.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>arc: cache - build invalidate_icache_all() and invalidate_dcache_all()</title>
<updated>2015-04-03T06:47:49+00:00</updated>
<author>
<name>Alexey Brodkin</name>
<email>abrodkin@synopsys.com</email>
</author>
<published>2015-03-27T09:47:29+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=ae4a351ad9e3b800e8eb55b27c302d8be256540e'/>
<id>ae4a351ad9e3b800e8eb55b27c302d8be256540e</id>
<content type='text'>
always

Make both invalidate_icache_all() and invalidate_dcache_all() available
even if U-Boot is configured with CONFIG_SYS_DCACHE_OFF and/or
CONFIG_SYS_ICACHE_OFF.

This is useful because configuration of U-Boot may not match actual
hardware features. Real board may have cache(s) but for some reason we
may want to run U-Boot with cache(s) disabled (for example if some
peripherals work improperly with existing drivers if data cache is
enabled). So board may start with cache(s) enabled (that's the case for
ARC cores with built-in caches) but early in U-Boot we disable cache(s)
and make sure all contents of data cache gets flushed in RAM.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
always

Make both invalidate_icache_all() and invalidate_dcache_all() available
even if U-Boot is configured with CONFIG_SYS_DCACHE_OFF and/or
CONFIG_SYS_ICACHE_OFF.

This is useful because configuration of U-Boot may not match actual
hardware features. Real board may have cache(s) but for some reason we
may want to run U-Boot with cache(s) disabled (for example if some
peripherals work improperly with existing drivers if data cache is
enabled). So board may start with cache(s) enabled (that's the case for
ARC cores with built-in caches) but early in U-Boot we disable cache(s)
and make sure all contents of data cache gets flushed in RAM.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;</pre>
</div>
</content>
</entry>
</feed>
