sh: share the correct version of start.S among all cpus

It is easy to note that SH2/SH3/SH4 start.S code is practically
the same with a minor difference for SH2 where a short data header is
present.

sh: share the correct version of start.S among all cpus

It is easy to note that SH2/SH3/SH4 start.S code is practically
the same with a minor difference for SH2 where a short data header is
present. To avoid unwanted code duplication and to automatically
convert SH2 and SH3 platforms to generic board support move fixed SH4
start.S into arch/sh/lib/start.S and share it among all platforms.

Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

sh4: fix start.S by calling board_init_f() after first code relocation

Like on ARM platform keep the first code relocation from a U-boot
image storage to RAM at CONFIG_SYS_TEXT_BASE, then pass execu

sh4: fix start.S by calling board_init_f() after first code relocation

Like on ARM platform keep the first code relocation from a U-boot
image storage to RAM at CONFIG_SYS_TEXT_BASE, then pass execution to a
generic board_init_f() with empty GD flags. If CONFIG_SYS_TEXT_BASE is
equal to a calculated by board_init_f() relocation address there will
be no more code and data copy, however it's worth to mention that the
first copy happens even if $pc on _start is the same as
CONFIG_SYS_TEXT_BASE, on practice this works without a problem.

Also note that _sh_start is renamed back to _start to correct
gd->mon_len calculation by setup_mon_len(), the opposite rename was
done in pre-generic board commit 2024b968ee9 ("sh: Fix build in start.S").

Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

sh: add shared relocate_code() function and call board_init_r()

Commits b61e90e6fd83 ("sh: Drop the arch-specific board init") and
f41e6088eb1a ("sh: Fix build errors for generic board") left code a

sh: add shared relocate_code() function and call board_init_r()

Commits b61e90e6fd83 ("sh: Drop the arch-specific board init") and
f41e6088eb1a ("sh: Fix build errors for generic board") left code and
data relocation done in start.S, however further actual U-boot
configuration is not started anymore. Practically SH boards with the
code relocated into the expected position by start.S still can be
booted, so the change adds this option and provides an option how to
relocate code for board_init_r() execution.

Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

sh: add common dram_init() function for all boards

Generic board support assumes a different method of specifying
DRAM size on board, also it can be shared among all boards, notably
only sh7763rdp b

sh: add common dram_init() function for all boards

Generic board support assumes a different method of specifying
DRAM size on board, also it can be shared among all boards, notably
only sh7763rdp board has a custom legacy dram_init(), however
the difference is only in printing some additional information,
this feature can be removed.

Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

sh: add MEMORY command to a shared linker script

At the moment in runtime all defined sections are copied into or
created in RAM, specify this explicitly to assert potential out of RAM
placements of

sh: add MEMORY command to a shared linker script

At the moment in runtime all defined sections are copied into or
created in RAM, specify this explicitly to assert potential out of RAM
placements of the sections.

Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

sh: define entry point and reloc_dst inside a linker script

No functional change, concentrate linker script commands in one
place for convenience. Entry point is set to CONFIG_SYS_TEXT_BASE by
defau

sh: define entry point and reloc_dst inside a linker script

No functional change, concentrate linker script commands in one
place for convenience. Entry point is set to CONFIG_SYS_TEXT_BASE by
default on build, so this option can be omitted from being added to
the linker script.

Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

sh: place board lowlevel_init code in the beginning of .text

Reference lowlevel_init of all supported SH2A/SH3/SH4/SH4A boards
from a shared linker script, the lowlevel_init function will be called

sh: place board lowlevel_init code in the beginning of .text

Reference lowlevel_init of all supported SH2A/SH3/SH4/SH4A boards
from a shared linker script, the lowlevel_init function will be called
by a relative address.

Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

sh4: use single u-boot linker script for all boards

Three supported SH4/SH4A boards with the bootloader image stored on
SPI flash have own flavour of a linker script, in turn they are equal
among ea

sh4: use single u-boot linker script for all boards

Three supported SH4/SH4A boards with the bootloader image stored on
SPI flash have own flavour of a linker script, in turn they are equal
among each other. The only difference is that the text from
lowlevel_init.o is placed right after start.o, which makes sense.

Note that .bss section is not marked as NOLOAD, because for about
10 years this is a default option of a GNU linker, either the
attribute is found or not the resulting image file is the same.

Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

sh4: remove __io config options from r2dplus and r7780mp boards

Defined __io is no-op for the SH architecture and it can be removed
from board files without any functional change.

Signed-off-by: Vl

sh4: remove __io config options from r2dplus and r7780mp boards

Defined __io is no-op for the SH architecture and it can be removed
from board files without any functional change.

Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

sh4: cache: move exported cache manipulation functions into cache.c

No functional change, moving cache manipulation functions into cache.c
allows to collect all of them in a single location and as a

sh4: cache: move exported cache manipulation functions into cache.c

No functional change, moving cache manipulation functions into cache.c
allows to collect all of them in a single location and as a pleasant
side effect cache_control() function can be unexported now.

Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

sh: cache: don't modify CCR from P1 area

cache_wback_all() is a local function and it is called from
cache_control() only, which is in turn jumps to P2 area.

The change fixes an issue when cache_wb

sh: cache: don't modify CCR from P1 area

cache_wback_all() is a local function and it is called from
cache_control() only, which is in turn jumps to P2 area.

The change fixes an issue when cache_wback_all() returns from P2 to
P1, however cache_control() continues to manipulate with CCR
register, according to the User's Manual this is restricted.

Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>

show more ...

sh: cache use jump_to_P2() and back_to_P1() from asm/system.h

Both jump_to_P2() and back_to_P1() functions are found in asm/system.h
header file and functionally they are the same, don't redefine th

sh: cache use jump_to_P2() and back_to_P1() from asm/system.h

Both jump_to_P2() and back_to_P1() functions are found in asm/system.h
header file and functionally they are the same, don't redefine them.

Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

sh3: remove unused cache.c file from being built

The change is similar to commit 994b56616bae ("sh: delete an unused
source file") for SH2, however here the removed cache.c file was
built and includ

sh3: remove unused cache.c file from being built

The change is similar to commit 994b56616bae ("sh: delete an unused
source file") for SH2, however here the removed cache.c file was
built and included into an image as a dead code.

If it is needed in future the contents can be reused from a similar
arch/sh/cpu/sh4/cache.c file, which is in turn will be moved to
a shared among all core flavours location at arch/sh/lib/cache.c.

Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

sh4: cache: correct flush_cache() to writeback and invalidate

In common usecases flush_cache() assumes both cache invalidation and
write-back to memory, instead of doing cache invalidation only with

sh4: cache: correct flush_cache() to writeback and invalidate

In common usecases flush_cache() assumes both cache invalidation and
write-back to memory, instead of doing cache invalidation only with
the wrapped 'ocbi' instruction pin flush_cache() to cache invalidation
with memory write-back done by 'ocbp'.

Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

sh4: cache: correct dcache flush to invalidate with write-back

In common usecases flush_cache() assumes both cache invalidation and
write-back to memory, thus in flush_dcache_range() implementation

sh4: cache: correct dcache flush to invalidate with write-back

In common usecases flush_cache() assumes both cache invalidation and
write-back to memory, thus in flush_dcache_range() implementation
change SH4 cache write-back only instruction 'ocbwb' with cache purge
instruction 'ocbp', according to the User's Manual there should be no
performance penalty for that.

Note that under circumstances only cache invalidation is expected from
flush_cache() call, in these occasional cases the current version of
flush_cache() works, which is a wrapper over invalidate_dcache_range()
at the moment, this will be fixed in the following change.

Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>

show more ...

efi: Use asmlinkage for EFIAPI

This is required for x86 and is also correct for ARM (since it is empty).

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Sig

efi: Use asmlinkage for EFIAPI

This is required for x86 and is also correct for ARM (since it is empty).

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>

show more ...