u-boot.git/arch/arc, branch v2018.03

fdt: Implement weak arch_fixup_fdt()

2018-02-18T19:53:38+00:00

Only ARM and in some configs MIPS really implement arch_fixup_fdt().
Others just use the same boilerplate which is not good by itself,
but what's worse if we try to build with disabled CONFIG_CMD_BOOTM
and enabled CONFIG_OF_LIBFDT we'll hit an unknown symbol which was
apparently implemented in arch/xxx/lib/bootm.c.

Now with weak arch_fixup_fdt() right in image-fdt.c where it is
used we get both items highlighted above fixed.

Signed-off-by: Alexey Brodkin 
Cc: Daniel Schwierzeck 
Cc: Simon Glass 
Cc: York Sun 
Cc: Stefan Roese 
Reviewed-by: Tom Rini 
Reviewed-by: Daniel Schwierzeck

arc: Fix final linkage with Elf32 tools

2018-02-15T12:44:47+00:00

ARC Elf32 tools by default enable usage of so-called "small data"
section or in ARC PRM parlance "GP-relative addressing".

The idea is to put up to 2kB of frequently used data into a separate
location and use indirect addressing via dedicated core register (GP).
Where GP is used as a base for offset calculation.

And so if "-msdata" toggle is passed to the compiler either explicitly
or implicitly (that's Elf32 tools case) it will try to put some data
in that "small data" area and then to calculate real offset from GP
to be encoded in instructions we need to know the base value which
liker gets from __SDATA_BEGIN__ symbol in hte linker script.

In U-Boot we don't use that feature and linker script doesn't define
__SDATA_BEGIN__ which gives us the following linkage error if we use
Elf32 tools:
------------------------->8-------------------
  LD      u-boot
.../bin/arc-elf32-ld.bfd: Error: Linker symbol __SDATA_BEGIN__ not found
.../bin/arc-elf32-ld.bfd: final link failed: Bad value
------------------------->8-------------------

Note if uClibc or glibc tools are used that problem doesn't happen
because usage of "small data section" is disabled by default as not very
useful for bigger executables. Moreover GP is just another name of r26
so we're loosing 1 core register which is not used by the compiler as a
generic register with "-msdata".

Signed-off-by: Alexey Brodkin

ARC: Invalidate instruction and data caches early on boot

2018-01-19T14:59:35+00:00

This is useful to make sure no stale data exists in caches after bootloaders.

The worst thing could be some lines of cache were locked in a bootloader
for example during DDR recalibration and never unlocked. This may lead
to really unpredictable issues later down the line.

Signed-off-by: Eugeniy Paltsev 
Signed-off-by: Alexey Brodkin

ARC: HSDK: DTS: Add cgu-clk node

2018-01-19T14:59:35+00:00

Add cgu-clk (clock generation unit) node to HSDK device tree.

Signed-off-by: Eugeniy Paltsev 
Signed-off-by: Alexey Brodkin

ARC: Cache: Fix style violations reported by checkpatch

2018-01-19T14:59:35+00:00

Signed-off-by: Eugeniy Paltsev 
Signed-off-by: Alexey Brodkin

ARC: Cache: Disable IOC by default

2018-01-19T14:59:34+00:00

We'd like to keep IOC HW at the same state as t is right after reset when we
start Linux kernel so there will be no re-configuration of IOC on the go.

The point is U-Boot doesn't benefit a lot from IOC as it doesn't do a
lot of DMA operations especially on multiple cores simultaneously.

At the same time re-configuration of IOC in run-time might become quite
a tricky experience because we need to make sure there're no DMA
trannsactions in flight otherwise unexpected consequencses might affect
us much later and debugging those kinds of issues will be a real
nightmare.

That said let's make our life easier a little bit.

Signed-off-by: Eugeniy Paltsev 
Signed-off-by: Alexey Brodkin

ARC: ARCv2: Cache: Fixed operation without IOC

2018-01-19T14:59:34+00:00

Previous SLC management implementation is broken. Seems like it was
never sufficiently tested probably because most of the time IOC was used
instead (i.e. no manual cache operations were done).

Now if we disable IOC in U-boot we'll get a lot of errors while using
DMA-enabled peripherals.

This time we fix it by substitution of broken per-line SLC operations
region operations as it is done in the Linux kernel (we took it from
v4.14 which is the latest stable as of today).

Among other things this implementation might be a bit faster because
instead of iteration over each and every cache line we're taking care
about entire region in one go.

Main changes:
 * Replaced __slc_line_op (per line operations) by __slc_rgn_op
   (region operations).

 * Reworked __slc_entire_op to get rid of __after_slc_op and
   __before_slc_op functions.
   Note flush fix (flush only instead of flush-n-inv when OP_FLUSH is
   used, see [1] for more details) is already incorporated here.

 * Added SLC invalidation to invalidate_icache_all().

 * Added (start >= end) check to invalidate_dcache_range() and
   flush_dcache_range() as some buggy drivers pass region start == end.

 * Added read-out of MMU BCR so we may know if PAE40 exists in HW and then
   act on a particular AUX regs accordingly.

[1] http://lists.infradead.org/pipermail/linux-snps-arc/2018-January/003357.html

Signed-off-by: Eugeniy Paltsev 
Signed-off-by: Alexey Brodkin

ARC: cache: explicitly initialize "*_exists" variables

2017-12-11T08:36:22+00:00

dcache_exists, icache_exists, slc_exists and ioc_exists global
variables in "arch/arc/lib/cache.c" remain uninitialized if
SoC doesn't have corresponding HW.

This happens because we use the next constructions for their
definition and initialization:
-------------------------->>---------------------
int ioc_exists __section(".data");

if (/* condition */)
		ioc_exists = 1;
-------------------------->>---------------------

That's quite a non-trivial issue as one may think of it.
The point is we intentionally put those variables in ".data" section
so they might survive relocation (remember we initilaize them very early
before relocation and continue to use after reloaction). While being
non-initialized and not explicitly put in .data section they would end-up
in ".bss" section which by definition is filled with zeroes.
But since we place those variables in .data section we need to care
about their proper initialization ourselves.

Also while at it we change their type to "bool" as more appropriate.

Signed-off-by: Eugeniy Paltsev 
Signed-off-by: Alexey Brodkin

ARC: add defines of some cache and xCCM AUX registers

2017-12-11T08:36:22+00:00

Signed-off-by: Eugeniy Paltsev 
Signed-off-by: Alexey Brodkin

ARC: add macro to get CPU id

2017-12-11T08:36:22+00:00

ARCNUM [15:8] field in ARC_AUX_IDENTITY register allows us to
uniquely identify each core in a multi-core system.

I.e. with help of this macro each core may get its index in SMP system.

Signed-off-by: Eugeniy Paltsev 
Signed-off-by: Alexey Brodkin