Andre Przywara [Wed, 16 Nov 2016 00:50:10 +0000 (00:50 +0000)]
marvell: comphy_a3700: fix bitmask
Obviously the mask for the rx and tx select field cannot be right,
as it would overlap in one and exceed the 32-bit register in the other
case. From looking at the neighbouring bits it looks like the mask
should be really 4 bits wide instead of 8.
Pointed out by a GCC 6.2 (default) warning.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Stefan Roese <sr@denx.de>
Andre Przywara [Wed, 16 Nov 2016 00:50:06 +0000 (00:50 +0000)]
mtd: cfi_flash: fix indentation
The indentation is misleading here and suggests that the write command
will be only executed in the else clause.
It seems like this is not intended, so fix the indentation to avoid
both compiler warnings and puzzled readers.
Pointed out by GCC 6.2's -Wmisleading-indentation warning.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Stefan Roese <sr@denx.de>
Lokesh Vutla [Fri, 25 Nov 2016 05:44:26 +0000 (11:14 +0530)]
ti_armv7_common: env: Increase IO buffer size
There are certain environment variables whose length is greater than
the defined IO buffer size. So, increase the IO buffer size to print the
entire variables.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Steve Kipisz [Fri, 25 Nov 2016 05:44:24 +0000 (11:14 +0530)]
board: ti: am57xx: Add support for the am571x idk
The AM571x Industrial Development Kit (IDK) is a board based on TI's
AM571x SoC which has a single core 1.5GHz Cortex-A15processor. This
board is a development platform for the Industrial Market with:
- 1GB of DDR3L
- Dual 1Gbps Ethernet
- HDMI
- PRU-ICSS
- uSD
- 16GB eMMC
- CAN
- RS-485
- PCIe
- USB3.0
- Video Input Port
- Industrial IO port and expansion connector
The PRU/ICSS will be supported by 3rd party software for EtherCat,
Profibus, and other Industrial protocols.
The link to the data sheet and TRM can be found here:
http://www.ti.com/product/AM5718
Signed-off-by: Steve Kipisz <s-kipisz2@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>
Lokesh Vutla [Fri, 25 Nov 2016 05:44:23 +0000 (11:14 +0530)]
board: ti: am572x-idk: Update pinmux using latest PMT
Update the board pinmux for AM572x-IDK board using latest PMT[1] and the
board files named am572x_idk_v1p3b_sr2p0 that were autogenerated on
20th October, 2016 by "Steve Kipisz <s-kipisz2@ti.com>" and
"Tom Johnson <thjohnson@ti.com>".
Nishanth Menon [Fri, 25 Nov 2016 05:44:22 +0000 (11:14 +0530)]
board: ti: am572x: Add pinmux for X15/GPEVM SR2.0 using latest PMT
Update the board pinmux for AM572x-IDK board using latest PMT[1] and the
board files named am572x_gp_evm_A3a_sr2p0 that were autogenerated on
19th October, 2016 by "Ahmad Rashed<a-rashed@ti.com>".
Lokesh Vutla [Fri, 25 Nov 2016 05:44:20 +0000 (11:14 +0530)]
board: ti: am57xx: Add support for detection of X15 revb1
BeagleBoard-X15 Rev B1 with SR1.1 platform have incompatible changes for HDMI
GPIO requiring new dtb support. This implies we have to properly identify
the platform now as well. Hence provide a different board name for the
Rev B1 variants.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Nishanth Menon [Fri, 25 Nov 2016 05:44:19 +0000 (11:14 +0530)]
board: ti: am57xx: Add support for detection of reva3 variations for GPEVM
AM57xx evm Rev A3 with SR2.0 platform have incompatible changes for HDMI
GPIO requiring new dtb support. This implies we have to properly identify
the platform now as well. Hence provide a different board name for the
Rev A3 variations.
Lokesh Vutla [Wed, 23 Nov 2016 07:55:28 +0000 (13:25 +0530)]
ARM: OMAP4+: Add support for getting pbias info from board
Palmas driver assumes it is always TPS659xx regulator on all DRA7xx based
boards to enable mmc regulator. This is not true always like in case of
DRA71x-evm. So get this information based on the board.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Vignesh R <vigneshr@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
[trini: Delete omap4_vmmc_pbias_config from omap_hsmmc.c] Signed-off-by: Tom Rini <trini@konsulko.com>
Keerthy [Wed, 23 Nov 2016 07:55:27 +0000 (13:25 +0530)]
board: ti: dra71x-evm: Add PMIC support
Add the pmic_data for LP873x PMIC which is used to power
up dra71x-evm.
Note: As per the DM[1] DRA71x supports only OP_NOM. So, updating
the efuse registers only to use OPP_NOM irrespective of any
CONFIG_DRA7_<VOLT>_OPP_{NOM,od,high} is defined.
Nishanth Menon [Wed, 23 Nov 2016 07:55:26 +0000 (13:25 +0530)]
board: ti: dra72: Introduce optimization for rgmii timing for rev C
Rev C version of EVM does require IODelay to be configured for RGMII
pins in MANUAL_1 configuration. Update the same based on PG2.0 initial
simulation values.
Data based on PCT_DRA72x_SR2.0_SR1.0_v1.3.0.7
Lokesh Vutla [Wed, 23 Nov 2016 07:55:24 +0000 (13:25 +0530)]
board: ti: dra71x-evm: Add epprom support
The dra71x-evm is a board based on TI's DRA718 processor targeting BOM-optimized
entry infotainment systems such as display audio and is a software compatible
derivative of the highly successful DRA74 and DRA72 processor families.
More information can be found here[1].
Add epprom detection for dra71-evm.
[1] http://www.ti.com/product/dra718
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Suman Anna [Wed, 23 Nov 2016 07:24:41 +0000 (12:54 +0530)]
ARM: DRA7: Fixup DSPEVE, IVA and GPU clock frequencies based on OPP
This patch adds support to update the device-tree blob to adjust the
DSP and IVA DPLL clocks pertinent to the selected OPP choice, with
the default being OPP_NOM. The voltage settings are done in u-boot,
but the actual clock configuration itself is done in kernel because
of the following reasons:
1. SoC definition constraints us to NOT to do dynamic voltage
scaling ever after the initial avs0 setting in bootloader
- so the voltage must be set in bootloader.
2. The voltage level must be set even if the IP blocks like
GPU/DSP are unused.
3. The IVA, GPU and DSP DPLLs are not essential for u-boot functionality,
and similar DPLL clock configuration code has been cleaned up in
v2014.10 u-boot release. See commit, 02c41535b6a4 ("ARM: OMAP4/5:
Remove dead code against CONFIG_SYS_CLOCKS_ENABLE_ALL").
The non-essential DPLLs are configured within the kernel during
the clock init step when parsing the device tree and creating
the clock devices. This approach meets both the u-boot and kernel
needs.
Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Subhajit Paul <subhajit_paul@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Suman Anna [Wed, 23 Nov 2016 07:24:40 +0000 (12:54 +0530)]
ARM: DRA7: Redefine voltage and efuse macros per OPP using Kconfig
Redefine the macros used to define the voltage values and the
efuse register offsets based on OPP for all the voltage domains.
This is done using Kconfig macros that can be set in a defconfig
or selected during a config step. This allows a voltage domain
to be configured/set to a corresponding voltage value depending
on the OPP selection choice.
The Kconfig choices have been added for MPU, DSPEVE, IVA and GPU
voltage domains, with the MPU domain restricted to OPP_NOM. The
OPP_OD and OPP_HIGH options will be added when the support for
configuring the MPU clock frequency is added. The clock
configuration for other voltage domains is out of scope in
u-boot code.
The CORE voltage domain does not have separate voltage values
and efuse register offset at different OPPs, while the MPU
voltage domain only has different efuse register offsets for
different OPPs, but uses the same voltage value. Any different
choices of OPPs for voltage domains on common ganged-rails
is automatically taken care to select the corresponding
highest OPP voltage value.
Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Lokesh Vutla [Wed, 23 Nov 2016 07:24:39 +0000 (12:54 +0530)]
ARM: OMAP4+: Add support for dynamically selecting OPPs
It can be expected that different paper spins of a SoC can have
different definitions for OPP and can have their own constraints
on the boot up OPP for each voltage rail. In order to have this
flexibility, add support for dynamically selecting the OPP voltage
based on the board to handle any such exceptions.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Yann E. MORIN [Sun, 13 Nov 2016 20:59:52 +0000 (21:59 +0100)]
cmd: move CMD_PXE to Kconfig
Currently, CMD_PXE is forcibly enabled in config_distro_defaults.h, so
that general purpose distributions can rely on it being defined. This
header is included, under conditions or not, by various archs or
famillies of archs / SoCs.
However, it is very possible that boards based on those SoCs will not
have a physical ethernet connector at all, even if the have a MAC; for
example, the Nanopi Neo AIR (sunxi H3) does not. It is also possible
that network booting is absolutely not necessary for a device.
However, it is not possible to disable the PXE command, as it is
forcibly enabled and is non-configurable.
But it turns out we already have a config option to build a distro-ready
image, in the name of DISTRO_DEFAULTS.
Move CMD_PXE out of the hard-coded config_distro_defaults.h into a
Kconfig option, that gets selected by DISTRO_DEFAULTS when it is set.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Joe Hershberger <joe.hershberger@ni.com>
[trini: Make it select MENU, run moveconfig.py] Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Tue, 29 Nov 2016 14:14:57 +0000 (09:14 -0500)]
Enable DISTRO_DEFAULT on platforms that missed it before
A number of platforms had been using the distro default feature before
it was moved to Kconfig but did not enable the new Kconfig option when
it was enabled. This caused a regression in terms of features and this
introduces breakage when more things move to Kconfig.
secure_tee_install is used to install and initialize a secure TEE OS such as
Linaro OP-TEE into the secure world. This function takes in the address
where the signed TEE image is loaded as an argument. The signed TEE image
consists of a header (struct tee_header), TEE code+data followed by the
signature generated using image signing tool from TI security development
package (SECDEV). Refer to README.ti-secure for more information.
This function uses 2 new secure APIs.
1. PPA_SERV_HAL_TEE_LOAD_MASTER - Must be called on CPU Core 0. Protected
memory for TEE must be reserved before calling this function. This API
needs arguments filled into struct ppa_tee_load_info. The TEE image is
authenticated and if there are no errors, the control passes to the TEE
entry point.
2. PPA_SERV_HAL_TEE_LOAD_SLAVE - Called on other CPU cores only after
a TEE_LOAD_MASTER call. Takes no arguments. Checks if TEE was
successfully loaded (on core 0) and transfers control to the same TEE
entry point.
The code at TEE entry point is expected perform OS initialization steps
and return back to non-secure world (U-Boot).
Signed-off-by: Harinarayan Bhatta <harinarayan@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
arm: omap5: Add function to make an SMC call on cpu1
On DRA7xx platform, CPU Core 1 is not used in u-boot. However, in some
cases it is need to make secure API calls from Core 1. This patch adds
an assembly function to make a secure (SMC) call from CPU Core #1.
Signed-off-by: Harinarayan Bhatta <harinarayan@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Andrew F. Davis [Tue, 29 Nov 2016 22:33:20 +0000 (16:33 -0600)]
image: Add FIT image loadable section custom processing
To help automate the loading of custom image types we add the ability
to define custom handlers for the loadable section types. When we find
a compatible type while loading a "loadable" image from a FIT image we
run its associated handlers to perform any additional steps needed for
loading this image.
Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Fabien Parent [Tue, 29 Nov 2016 13:31:34 +0000 (14:31 +0100)]
davinci: omapl138_lcdk: add NAND SPL boot support
NAND SPL boot was missing. Add it. The README specific to omapl138-lcdk
is also removed because its content does not apply anymore, i.e. the
generated AIS image can be flashed directly to the NAND without
using any external tool to create and bootable AIS image.
Signed-off-by: Fabien Parent <fparent@baylibre.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Fabien Parent [Tue, 29 Nov 2016 13:31:32 +0000 (14:31 +0100)]
davinci: omapl138_lcdk: use correct name for CONFIG_SYS_NAND_MASK_ALE
CONFIG_SYS_ALE_MASK is not used anywhere. It has probably been
renamed to CONFIG_SYS_NAND_MASK_ALE. Rename it and remove the former
from the config_whitelist.txt file.
Signed-off-by: Fabien Parent <fparent@baylibre.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Fabien Parent [Tue, 29 Nov 2016 13:31:31 +0000 (14:31 +0100)]
davinci: omapl138_lcdk: use correct name for CONFIG_SYS_NAND_MASK_CLE
CONFIG_SYS_CLE_MASK is not used anywhere. It has probably been
renamed to CONFIG_SYS_NAND_MASK_CLE. Rename it and remove the former
from the config_whitelist.txt file.
Signed-off-by: Fabien Parent <fparent@baylibre.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Fabien Parent [Tue, 29 Nov 2016 13:31:30 +0000 (14:31 +0100)]
davinci: omapl138_lcdk: use correct define for 16 bit NAND chips
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>
Nishanth Menon [Tue, 29 Nov 2016 09:52:00 +0000 (15:22 +0530)]
ARM: DRA7x/AM57xx: Get rid of CONFIG_AM57XX
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>
Nishanth Menon [Tue, 29 Nov 2016 09:51:59 +0000 (15:21 +0530)]
usb: xhci: Remove assumption of DWC instance based on DRA7 SoC type
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.
Nishanth Menon [Tue, 29 Nov 2016 06:37:50 +0000 (12:07 +0530)]
ARM: K2G: DDR3: Fix up priv ID for MPU
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.
Lokesh Vutla [Tue, 29 Nov 2016 06:28:00 +0000 (11:58 +0530)]
ti_armv7_common: env: Add support for loading FIT images
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>
Lokesh Vutla [Tue, 29 Nov 2016 06:27:59 +0000 (11:57 +0530)]
ti_armv7_common: env: Consolidate support for loading images from mmc
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.
Mugunthan V N [Thu, 17 Nov 2016 09:08:10 +0000 (14:38 +0530)]
drivers: usb: musb: adopt musb backend driver to driver model
Currently all backend driver ops uses hard coded physical
address, so to adopt the driver to DM, add device pointer to ops
call backs so that drivers can get physical addresses from the
usb driver priv/plat data.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Mugunthan V N [Thu, 17 Nov 2016 09:08:09 +0000 (14:38 +0530)]
am33xx: board: probe misc drivers to register musb devices
MUSB wrapper driver is bound as MISC device and underlying usb
devices are bind to usb drivers based on dr_mode, so probing the
MISC wrapper driver to register musb devices.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Stefan Roese [Wed, 30 Nov 2016 06:24:47 +0000 (07:24 +0100)]
dm: core: Add dev_get_addr_size_index() to retrieve addr and size
The currently available functions accessing the 'reg' property of a
device only retrieve the address. Sometimes its also necessary to
retrieve the size described by the 'reg' property. This patch adds
the new function dev_get_addr_size_index() which retrieves both,
the address and the size described by the 'reg' property.
Signed-off-by: Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
Masahiro Yamada [Sat, 26 Nov 2016 02:02:10 +0000 (11:02 +0900)]
libfdt: replace ARCH_FIXUP_FDT with ARCH_FIXUP_FDT_MEMORY
Commit e2f88dfd2d96 ("libfdt: Introduce new ARCH_FIXUP_FDT option")
allows us to skip memory setup of DTB, but a problem for ARM is that
spin_table_update_dt() and psci_update_dt() are skipped as well if
CONFIG_ARCH_FIXUP_FDT is disabled.
This commit allows us to skip only fdt_fixup_memory_banks() instead
of the whole of arch_fixup_fdt(). It will be useful when we want to
use a memory node from a kernel DTB as is, but need some fixups for
Spin-Table/PSCI.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Alexey Brodkin <abrodkin@synopsys.com> Acked-by: Simon Glass <sjg@chromium.org>
Fixed build error for x86: Signed-off-by: Simon Glass <sjg@chromium.org>
Fabien Parent [Thu, 24 Nov 2016 14:02:18 +0000 (15:02 +0100)]
cmd/fdt: fix uncallable systemsetup command
The function that is processing the 'fdt' parameters is one big
if-else if. In order to be able to type command faster only the first
few letter are checked to know which block of code to execute. For
systemsetup, the block of code that was executed was always the wrong
one and ended up in a failure.
} else if (argv[1][0] == 's') {
process "fdt set" command
} else if (strncmp(argv[1], "sys", 3) == 0) {
process "fdt systemsetup" command.
}
When typing "fdt systemsetup", the code that was executed was the code
for "fdt set".
This commit fix this issue by moving the "else if" for systemsetup
before the else if for "fdt set". This allow us to keep compatibility
with any script that make use of "fdt s" to set node values.
Signed-off-by: Fabien Parent <fparent@baylibre.com> Acked-by: Simon Glass <sjg@chromium.org>
Mugunthan V N [Fri, 18 Nov 2016 05:36:13 +0000 (11:06 +0530)]
drivers: usb: gadget: ether: consolidate global devices to single struct
Consolidate the net device, usb eth device and gadget device
struct to single struct and a single global variable so that the
same can be passed as priv of ethernet driver.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Simon Glass [Sun, 13 Nov 2016 21:21:58 +0000 (14:21 -0700)]
dm: core: Handle global_data moving in SPL
When CONFIG_SPL_STACK_R is enabled, and spl_init() is called before
board_init_r(), spl_relocate_stack_gd() will move global_data to a new
place in memory. This affects driver model since it uses a list for the
uclasses. Unless this is updated the list will become invalid. When
looking for a non-existent uclass, such as when adding a new one, the loop
in uclass_find() may continue forever, thus causing a hang.
Add a function to correct this rather obscure bug.
r2dplus: fixup CONFIG_SYS_TEXT_BASE to account arch/sh changes
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.
sh: generate position independent code for all platforms
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.
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>
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>
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>
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>
sh: define CONFIG_DISPLAY_BOARDINFO to print board information
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>
sh: remove undefined DEBUG preprocessor token from board config files
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>
projects / u-boot / log