The omapl138_lcdk header defines CONFIG_SYS_NAND_BUSWIDTH_16_BIT while
the correct name is CONFIG_SYS_NAND_BUSWIDTH_16BIT.
While renaming the only occurrence of CONFIG_SYS_NAND_BUSWIDTH_16_BIT,
let's also remove it from the config_whitelist.txt file.

Signed-off-by: Fabien Parent <fparent@baylibre.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

The OMAPL138-LCD board uses a NAND chip with a 16 bits bus. Add
support into the davinci driver for 16 bit bus NAND chips.

Signed-off-by: Fabien Parent <fparent@baylibre.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Set the correct CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR value in order
to be able to boot from MMC/SD.

The SPL is stored at sector 0x75, while u-boot will follow at
sector 0xb5.

Signed-off-by: Fabien Parent <fparent@baylibre.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

The list of available boot method is not part of the binary which
prevent the SPL from booting u-boot or Linux.

Add the missing .u_boot_list* sections to the binary to fix it.

Signed-off-by: Fabien Parent <fparent@baylibre.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

The SPL is unable to load u-boot because the DDR2 is not configured.
Configure the DDR2.

Signed-off-by: Fabien Parent <fparent@baylibre.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

The SPL is not able to boot properly because the PLL0 is not
configured. Configure it.

Signed-off-by: Fabien Parent <fparent@baylibre.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Clean config headers by moving CONFIG_SYS_DA850_DDR_INIT away to a
Kconfig file.

Signed-off-by: Fabien Parent <fparent@baylibre.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Clean config headers by moving CONFIG_SYS_DA850_PLL_INIT away to a
Kconfig file.

Signed-off-by: Fabien Parent <fparent@baylibre.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

CONFIG_AM57XX is just an unnecessary macro that is redundant given So,
remove the same instead of spreading through out the u-boot source
code and getting in the way to maintain common code for DRA7x family.

Acked-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Both AM57xx and DRA7xx share the same set of base addresses for DWC
controllers. The usage however differ with DWC2 instance used typically
in AM57xx evms while DWC1 instances used in DRA7x platforms.

Use TARGET_SOC config to differentiate so that CONFIG_AM57XX can be dropped.

Eventually, this needs to be dt-fied.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

For ECC enabled DDR, we use EDMA to reset all memory values to 0. For
K2E/L/H/K the priv ID of 8 was indicative of ARM, but that is not the
case for K2G, where it is 1.

Unfortunately, ddr3 code had hard coded the privID and had missed
identification previously. Fix the same, else unforeseen behavior can
be expected in our reset of DDR contents to 0 for ECC enablement.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Verification has to be done before booting any images on HS devices. So
default the boot to FIT on HS devices.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Verification has to be done before booting any images on HS devices. So
default the boot to FIT on HS devices.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Verification has to be done before booting any images on HS devices. So
default the boot to FIT on HS devices.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

FIT is a new image format which is a Tree like structure and gives more
flexibility in handling of various images. Mainly used for unification of
multiple images in a single blob and provide security information for each
image.

U-Boot already has support for loading such images, so adding the environment
support to load FIT image on all TI platforms.

Reviewed-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Support for loading images from mmc is duplicated in all TI platforms.
Add this information to DEFAULT_MMC_TI_ARGS so that it can be reused
in all TI platforms.

Reviewed-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

An issue in the TI secure image generation tool causes the ROM to
load the SPL at a different load address than what is specified by
CONFIG_ISW_ENTRY_ADDR while doing a peripheral boot.

This causes the SPL to fail on secure devices during peripheral
boot.

The TI secure image generation tool has been fixed so that the SPL
will always be loaded at 0x403018E0 by the ROM code for both
peripheral and memory boot modes. am43x hs defconfig file have been
updated to reflect this change.

Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

This change allows to reserve enough space at the end of board SDRAM
to store two copies of U-Boot and malloc heap.

Due to selection of the CONFIG_SYS_TEXT_BASE the second code/data
copying is not avoided, first of all this may depend on a used
toolchain, secondly at this point some level of volatility is wanted
to do more platform changes and do not care about probably changed
calculated in runtime relocation offset.

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

Finally add fpic compilation option to produce relocatable code.
Note that this requires to define CONFIG_NEEDS_MANUAL_RELOC for all
board files, also relocation support still has some limitations
(e.g. a developer should care not to overwrite the executing code or
memset() with zeroes not yet relocated data on malloc init etc.),
which may be fixed while switching to PIE.

Due to short investigation the architecture code is not ready for PIE
linking, this will require some manipulations with .dyn* sections.

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

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>

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 2024b968 ("sh: Fix build in start.S").

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

Commits b61e90e6 ("sh: Drop the arch-specific board init") and
f41e6088 ("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>

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>

All SH boards define a checkboard() function which outputs basic board
information on boot, however generic board support requires to define
CONFIG_DISPLAY_BOARDINFO to do that, so define it for the boards.

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

By default this undef is a noop, moreover at this point when the
platform support is broken is prevents debugging of U-boot by manual
insertion of #define DEBUG into common files, so it makes sense to
remove the option from all SH boards as a harmful one.

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

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>

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>

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>

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>

Since a platform conversion to generic board support has not been
accomplished some architecture specific bits are missing from board_f
init sequence, the change adds a number of basic expected callbacks
into early init sequence.

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

CONFIG_RTL8139 was moved to a board defconfig by a commit 86e9dc86
("net: Move CONFIG_RTL8139 to Kconfig"), however it was done
incorrectly due to a missing CONFIG_NETDEVICES selection, thus
virtually it was just a removal of the driver compilation.

As an unlucky consequence the option was completely removed by a purge
commit adad96e6 ("configs: Re-sync HUSH options"), restore the
driver inclusion back.

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

While both options are acceptable use P1 area physical addresses
instead of external memory space of text base and PCI system memory
for unification purposes, all other supported superh boards have the
same selection.

This allows to easily ensure that CONFIG_SYS_TEXT_BASE is located
within available DRAM.

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

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>

For ease of use and accounting a condition that on SH4
pci_phys_to_bus() and pci_bus_to_phys() are one in one mappings due to
unimplemented __iomem() conversion, this change fixes access to SDRAM
memory by PCI devices.

This change also generalizes PCI system memory configuration, which is
taken from board specific defines rather than hardcoded in the PCI
host driver.

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

The change actually maps PCI I/O window to the same address on PCI bus
as it is stated by a comment, before the change transfers to the PCI I/O
space are failed due to misconfiguration of the most significant 14 bits
of the PCI address in PCIIOBR (note that it is set to 0x0).

Most probably the problem remained unnoticed, because communcation
to all tested PCI devices is done over PCI memory space only.

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

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>

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>

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>

The change is similar to commit 994b5661 ("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>

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>