<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/arch/arc/lib, branch v2016.03</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: cache - utilize IO coherency (AKA IOC) engine</title>
<updated>2016-02-20T08:20:05+00:00</updated>
<author>
<name>Alexey Brodkin</name>
<email>Alexey.Brodkin@synopsys.com</email>
</author>
<published>2015-12-14T14:15:13+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=db6ce2312dcae87619136457d1f9df56789f630a'/>
<id>db6ce2312dcae87619136457d1f9df56789f630a</id>
<content type='text'>
With release of ARC HS38 v2.1 new IO coherency engine could be built-in
ARC core. This hardware module ensures coherency between DMA-ed data
from peripherals and L2 cache.

With L2 and IOC enabled there's no overhead for L2 cache manual
maintenance which results in significantly improved IO bandwidth.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With release of ARC HS38 v2.1 new IO coherency engine could be built-in
ARC core. This hardware module ensures coherency between DMA-ed data
from peripherals and L2 cache.

With L2 and IOC enabled there's no overhead for L2 cache manual
maintenance which results in significantly improved IO bandwidth.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arc: cache - accommodate different L1 cache line lengths</title>
<updated>2016-02-20T08:19:53+00:00</updated>
<author>
<name>Alexey Brodkin</name>
<email>Alexey.Brodkin@synopsys.com</email>
</author>
<published>2015-12-14T14:14:46+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=379b3280b30c4aad5ff0fdf1cd6431c5fa6861b1'/>
<id>379b3280b30c4aad5ff0fdf1cd6431c5fa6861b1</id>
<content type='text'>
ARC core could be configured with different L1 and L2 (AKA SLC) cache
line lengths. At least these values are possible and were really used:
32, 64 or 128 bytes.

Current implementation requires cache line to be selected upon U-Boot
configuration and then it will only work on matching hardware. Indeed
this is quite efficient because cache line length gets hardcoded during
code compilation. But OTOH it makes binary less portable.

With this commit we allow U-Boot to determine real L1 cache line length
early in runtime and use this value later on. This extends portability
of U-Boot binary a lot.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ARC core could be configured with different L1 and L2 (AKA SLC) cache
line lengths. At least these values are possible and were really used:
32, 64 or 128 bytes.

Current implementation requires cache line to be selected upon U-Boot
configuration and then it will only work on matching hardware. Indeed
this is quite efficient because cache line length gets hardcoded during
code compilation. But OTOH it makes binary less portable.

With this commit we allow U-Boot to determine real L1 cache line length
early in runtime and use this value later on. This extends portability
of U-Boot binary a lot.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix board init code to respect the C runtime environment</title>
<updated>2016-01-14T02:05:17+00:00</updated>
<author>
<name>Albert ARIBAUD</name>
<email>albert.u.boot@aribaud.net</email>
</author>
<published>2015-11-25T16:56:32+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=ecc306639e83c9019a5093b77a48685ea40eedc2'/>
<id>ecc306639e83c9019a5093b77a48685ea40eedc2</id>
<content type='text'>
board_init_f_mem() alters the C runtime environment's
stack it is actually already using. This is not a valid
behaviour within a C runtime environment.

Split board_init_f_mem into C functions which do not alter
their own stack and always behave properly with respect to
their C runtime environment.

Signed-off-by: Albert ARIBAUD &lt;albert.u.boot@aribaud.net&gt;
Acked-by: Thomas Chou &lt;thomas@wytron.com.tw&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
board_init_f_mem() alters the C runtime environment's
stack it is actually already using. This is not a valid
behaviour within a C runtime environment.

Split board_init_f_mem into C functions which do not alter
their own stack and always behave properly with respect to
their C runtime environment.

Signed-off-by: Albert ARIBAUD &lt;albert.u.boot@aribaud.net&gt;
Acked-by: Thomas Chou &lt;thomas@wytron.com.tw&gt;
</pre>
</div>
</content>
</entry>
<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>
</feed>
