Patches that added the Tegra210 pinctrl driver and renamed directories
arch/arm/cpu/tegra{$soc}-common -> arch/arm/mach-tegra/tegra-${soc}
crossed. Move the Tegra210 pinctrl driver to the correct location. This
wasn't detected since Tegra210 support is in the process of being added,
and isn't buildable yet.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
make the CPU clock selectable via Kconfig
this removes the sunxi specific CONFIG_CLK_FULL_SPEED defined in each
soc header and replaces it's use in board/sunxi/board.c with
CONFIG_SYS_CLK_FREQ from Kconfig which allows us to configure board
specific frequency on boot
Signed-off-by: Iain Paton <ipaton0@gmail.com>
[hdegoede@redhat.com s/CONFIG_SYS_CLK_FREQ/CONFIG_TIMER_CLK_FREQ/ for the
arch-timer clk speed on sun7i to fix mis-compile on sun7i]
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
clock_set_pll1 would pick the next highest available cpu clock speed if
a value not in the pre defined table was selected. this potentially
results in overclocking the soc.
reverse the selection method so that we select the next lowest speed
and add the missing 912Mhz setting that's requested by sun7i which also
uses the sun4i clock code.
Signed-off-by: Iain Paton <ipaton0@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The usb0 / otg phy on sunxi boards has a bug where it wrongly detects a
high speed squelch on usb reset deassert when a lo speed device is plugged in.
The android kernel has a work around for this in the form of temporary
disabling the phy's squelch detection on reset deassert, this commit adds
the same workaround to the u-boot sunxi musb code, thereby fixing various usb
lo speed devices not working.
Tested with a (before non working) usb keyboard and a usb 2.4 GHz wireless
keyboard/mouse combo receiver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Now that loading files using semihosting can be done using
a command in standard scripts, and we have rewritten the boardfile
and added it to the Vexpress64, let's delete the external
interface to the semihosting file retrieveal and rely solely
on these commands, and staticize them inside that file so the
whole business is self-contained.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Instead of sprinkling custom code and calls over the Vexpress64
boardfile, create a command that loads images using semihosting
just like we would load from flash memory of over the network,
using a special command:
smhload <image> <address>
This will make it possible to remove some custom calls and
code and make the boot easier.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The semihosting trap call does not like being inlined, probably
because that will mean register reordering screwing up the return
value in r0, so tag this function "noinline".
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
BCM2835 (used on Raspberry Pi) and BCM2836 (used on Raspberry Pi 2)
are similar enough. One of the biggest differences is the ARM
processor. It is reasonable to collect the source files into a
single place, arch/arm/mach-bcm283x/.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
This option has a bool type, not hex.
Fix it and enable it if CONFIG_DM is on because Driver Model always
requires malloc memory. Devices are scanned twice, before/after
relocation. CONFIG_SYS_MALLOC_F should be enabled to use malloc
memory before relocation. As it is board-independent, handle it
globally.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Robert Baldyga <r.baldyga@samsung.com>
The default value of CONFIG_SYS_MALLOC_F_LEN is defined by ./Kconfig
as 0x400. Each defconfig or Kconfig need not repeat the same value.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Robert Baldyga <r.baldyga@samsung.com>
Move the option to Kconfig renaming it to CONFIG_HAVE_GENERIC_BOARD.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alexey Brodkin <abrodkin@synopsys.com>
My main motivations for this commit are:
[1] Follow the arch/arm/Makefile style of Linux Kernel
[2] Maintain compiler options systematically
Currently, we give -march=* and -mtune=* options inconsistently:
Only some of the CPUs pass -march=* and -mtune=* options.
By collecting such options into the single place arch/arm/Makefile
we can tell which options are missing at a glance.
[3] Prepare for deprecating arch/*/cpu/*/config.mk
Note:
This commit just moves the compiler options so as not to change
the behavior at all. It does not care about the correctness of
the given options. Fox example, "-march=armv5te" might be better
than "-march=armv4" for ARM946EJS, but it is beyond the scope this
commit. Also, filling the missing -march=* and -tune=* is left
to follow-up patches.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Marek Vasut <marex@denx.de>
Acked-by: Stefan Roese <sr@denx.de>
Allocate memory space for pre-allocation malloc and zero global data.
This code is partly from crt0.S.
Signed-off-by: David Feng <fenghua@phytium.com.cn>
Various files are needlessly rebuilt every time due to the version and
build time changing. As version.h is not actually needed, remove the
include.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Tom Warren <twarren@nvidia.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Macpaul Lin <macpaul@andestech.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: York Sun <yorksun@freescale.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Philippe Reynes <tremyfr@yahoo.fr>
Cc: Eric Jarrige <eric.jarrige@armadeus.org>
Cc: "David Müller" <d.mueller@elsoft.ch>
Cc: Phil Edworthy <phil.edworthy@renesas.com>
Cc: Robert Baldyga <r.baldyga@samsung.com>
Cc: Torsten Koschorrek <koschorrek@synertronixx.de>
Cc: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Łukasz Majewski <l.majewski@samsung.com>
The callee (arch/arm/lib/cache-cp15.c) has a #ifdef
CONFIG_SYS_DCACHE_OFF conditional. The same conditional in the
caller (arch/arm/mach-uniphier/cache_uniphier.c) is redundant.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The L2 cache is used as a temporary SRAM on SPL.
Now the secondary CPUs store the necessary code for jumping to
Linux on their L1 I-caches. So, the L2 cache can be disabled
much earlier, at the very entry of U-Boot proper (lowlevel_init).
This makes the boot sequence clearer.
Also, as the L1 cache has been disabled by the start.S,
enable_caches() does not need to do it again.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, the secondary CPU(s) are kicked three times:
Boot ROM ---(kick)--> SPL ---(kick)--> U-boot ---(kick)--> Linux.
It makes the boot sequence very complicated.
This commit merges the first and the second kicks, so the secondary
CPU(s) can directly jump from SPL to Linux.
arch/arm/mach-uniphier/smp.S is no longer necessary.
Linux boot test passed.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
To remove the ifdef conditional of CONFIG_SKIP_LOWLEVEL_INIT,
add late_lowlevel_init.S to U-Boot proper.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Ifdef conditionals for CONFIG options are not Kconfig-friendly.
Instead, define CONFIG_SPL_STACK to prepare for Kconfig moves.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Enable CONFIG_SPL_DM and CONFIG_SPL_SERIAL_SUPPORT, which provide
Driver Model UART support on SPL.
CONFIG_SYS_SPL_MALLOC_{START,SIZE} should be dropped because simple
malloc is preferred on SPL. Dlmalloc requires some static variables
on .data section that is not available yet for NOR boot mode etc.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The UniPhier platform is going to enable Driver Model and UART
support on SPL. Move UART pin settings to early_pin_init(),
which is called from SPL.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Since we do not have OF_CONTROL support for SPL, platform devices
are necessary to enable Driver Model on SPL.
To prepare for that, move platdevice.o to SPL and enable it by
CONFIG_SPL_DM.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The two Makefiles arch/arm/mach-uniphier/{ph1-ld4,ph1-sld8}/Makefile
are completely the same. We can improve the maintainability by
having one to include the other.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Since commit a86ac9540e (ARM: UniPhier: include <mach/*.h> instead
of <asm/arch/*.h>), UniPhier platform does not need the symbolic
link arch/arm/include/asm. This option is not necessary either.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Add basic SECO MX6Q/uQ7 board support (Ethernet, UART, SD are supported).
It also adds a Kconfig skeleton to later add more SECO board (supporting
SoC and board variants).
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
IMX_CONFIG is currently passed via the SYS_EXTRA_OPTIONS which is marked
as deprecated.
Add a new Kconfig file under arch/arm/imx-common and define the
IMX_CONFIG Kconfig in there.
Each board is supposed to provide a default value pointing to the
appropriate imximage.cfg file.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Freescale boards are currently all defined in arch/arm/Kconfig, which
makes them hard to detect.
Moreover the MX6 SoC variant (Q, D, DL, S, SL) selection is currently
done via the SYS_EXTRA_OPTIONS option which marked as deprecated.
Move to a more standard way to select sub-architecture and board by
creating a Kconfig under arch/arm/cpu/armv7/mx6 and a new ARCH_MX6
option.
Existing MX6 board definitions should be moved in this new Kconfig in
choice menu, and new boards should be directly declared in this menu.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
As the u-boot-spl.lds is used only for armv7 SoCs (includes
sama5d3 and sama5d4), so move it to armv7 directory.
Signed-off-by: Bo Shen <voice.shen@atmel.com>
This patch enable the MCI support for at91sam9rlek board.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
[rebase on ToT]
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Panasonic's System LSI products, UniPhier SoC family, have been
transferred to Socionext Inc.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
RX51 has a secure logic which uses different parameters compared to
traditional implementation. So, make the generic secure acr write
over-ride-able by board file and refactor rx51 code to use this.
While at it, enable the OMAP3 specific errata code for 454179, 430973,
621766.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Enable the OMAP3 specific errata code for 454179, 430973, 621766
and while at it, remove legacy non-revision checked errata logic.
Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Matt Porter <mporter@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Update to existing recommendation for L2ACTLR configuration to prevent
system instability and optimize performance.
These apply to both OMAP5 and DRA7.
Reported-by: Vivek Chengalvala <vchengalvala@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
This patch enables the workaround for ARM errata 798870 for OMAP5 /
DRA7 which says "If back-to-back speculative cache line fills (fill
A and fill B) are issued from the L1 data cache of a CPU to the
L2 cache, the second request (fill B) is then cancelled, and the
second request would have detected a hazard against a recent write or
eviction (write B) to the same cache line as fill B then the L2 logic
might deadlock."
An l2auxctlr accessor implementation for OMAP5 and DRA7 is introduced
here as well.
Signed-off-by: Praveen Rao <prao@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Matt Porter <mporter@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
omap_smc1 is now generic enough to remove duplicate
omap3_gp_romcode_call logic that omap3 introduced.
As part of this change, move to using the generic lowlevel_init.S for
omap3 as well.
Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Matt Porter <mporter@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
This is in preperation of using generic cross OMAP code.
Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Matt Porter <mporter@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
set_pl310_ctrl_reg does use the Secure Monitor Call (SMC) to setup
PL310 control register, however, that is something that is generic
enough to be used for OMAP5 generation of processors as well. The only
difference being the service being invoked for the function.
So, convert the service to a macro and use a generic name (same as
that used in Linux for some consistency). While at that, also add a
data barrier which is necessary as per recommendation.
While at this, smc #0 is maintained as handcoded assembly thanks to
various gcc version eccentricities, discussion thread:
http://marc.info/?t=142542166800001&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Matt Porter <mporter@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
621766: Under a specific set of conditions, executing a sequence of
NEON or vfp load instructions can cause processor deadlock
Impacts: Every Cortex-A8 processors with revision lower than r2p1
Work around: Set L1NEON to 1
Based on ARM errata Document revision 20.0 (13 Nov 2010)
Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Matt Porter <mporter@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
430973: Stale prediction on replaced inter working branch causes
Cortex-A8 to execute in the wrong ARM/Thumb state
Impacts: Every Cortex-A8 processors with revision lower than r2p1
Work around: Set IBE to 1
Based on ARM errata Document revision 20.0 (13 Nov 2010)
Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Matt Porter <mporter@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
454179: Stale prediction may inhibit target address misprediction on
next predicted taken branch
Impacts: Every Cortex-A8 processors with revision lower than r2p1
Work around: Set IBE and disable branch size mispredict to 1
Also provide a hook for SoC specific handling to take place if needed.
Based on ARM errata Document revision 20.0 (13 Nov 2010)
Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Matt Porter <mporter@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add workaround for Cortex-A15 ARM erratum 798870 which says
"If back-to-back speculative cache line fills (fill A and fill B) are
issued from the L1 data cache of a CPU to the L2 cache, the second
request (fill B) is then cancelled, and the second request would have
detected a hazard against a recent write or eviction (write B) to the
same cache line as fill B then the L2 logic might deadlock."
Implementations for SoC families such as Exynos, OMAP5/DRA7 etc
will be widely different.
Every SoC has slightly different manner of setting up access to L2ACLR
and similar registers since the Secure Monitor handling of Secure
Monitor Call(smc) is diverse. Hence an weak function is introduced
which may be overriden to implement SoC specific accessor implementation.
Based on ARM errata Document revision 18.0 (22 Nov 2013)
Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Matt Porter <mporter@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Disable the warm reset and enable the cold reset for a more reliable
restart ('reset'). This is taken from the Linux kernel, see imx_src_init()
in arch/arm/mach-imx/src.c.
Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
While the Freescale ARMv8 board LS2085A will enter U-Boot both
on a master and a secondary (slave) CPU, this is not the common
behaviour on ARMv8 platforms. The norm is that U-Boot is entered
from the master CPU only, while the other CPUs are kept in
WFI (wait for interrupt) state.
The code determining which CPU we are running on is using the
MPIDR register, but the definition of that register varies with
platform to some extent, and handling multi-cluster platforms
(such as the Juno) will become cumbersome. It is better to only
enable the multiple entry code on machines that actually need
it and disable it by default.
Make the single entry default and add a special
ARMV8_MULTIENTRY KConfig option to be used by the
platforms that need multientry and set it for the LS2085A.
Delete all use of the CPU_RELEASE_ADDR from the Vexpress64
boards as it is just totally unused and misleading, and
make it conditional in the generic start.S code.
This makes the Juno platform start U-Boot properly.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The way the PSCI DT update happens currently means we pull in
<asm/armv7.h> everywhere, including on ARMv8 and that in turn brings in
<asm/io.h> for some non-PSCI related things that header needs to deal
with.
To fix this, we rework the hook slightly. A good portion of
arch/arm/cpu/armv7/virt-dt.c is common looking and I hope that when PSCI
is needed on ARMv8 we can re-use this by and large. So rename the
current hook to psci_update_dt(), move the prototype to <asm/psci.h> and
add an #ifdef that will make re-use later easier.
Reported-by: York Sun <yorksun@freescale.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: York Sun <yorksun@freescale.com>
Cc: Ian Campbell <ijc@hellion.org.uk>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: York Sun <yorksun@freescale.com>
For ARM architecture, enable the CONFIG_USE_ARCH_MEMSET/MEMCPY,
will highly increase the memset/memcpy performance. This is able
thanks to the ARM multiple register instructions.
Unfortunatelly the relocation is done without the cache enabled,
so it takes some time, but zeroing the BSS memory takes much more
longer, especially for the configs with big static buffers.
A quick test confirms, that the boot time improvement after using
the arch memcpy for relocation has no significant meaning.
The same test confirms that enable the memset for zeroing BSS,
reduces the boot time.
So this patch enables the arch memset for zeroing the BSS after
the relocation process. For ARM boards, this can be enabled
in board configs by defining: 'CONFIG_USE_ARCH_MEMSET'.
This was tested on Trats2.
A quick test with trace. Boot time from start to main_loop() entry:
- ~1384ms - before this change
- ~888ms - after this change
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Tom Rini <trini@konsulko.com>
The 'nandecc sw' command selects a software-based error correction
algorithm. By default, this is OMAP_ECC_HAM1_CODE_SW but some
platforms use OMAP_ECC_BCH8_CODE_HW_DETECTION_SW as their
software-based correction algorithm. Allow a user to be specific e.g.
# nandecc sw <hamming|bch8>
where 'hamming' is still the default.
Note: we don't just use CONFIG_NAND_OMAP_ECCSCHEME as it might be set
to a hardware-based ECC scheme---a little strange when the user
has requested 'sw' ECC.
Signed-off-by: Ash Charles <ashcharles@gmail.com>
This patch extends OMAP3 support for AM/DM37xx and
introduces the AM3703-based Quipos Cairo board.
Signed-off-by: Albert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr>
Reviewed-by: Simon Glass <sjg@chromium.org>
esbc_validate command uses various IP Blocks: Security Monitor, CAAM block
and SFP registers. Hence the respective CONFIG's are enabled.
Apart from these CONFIG_SHA_PROG_HW_ACCEL and CONFIG_RSA are also enabled.
Signed-off-by: Gaurav Rana <gaurav.rana@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
According to table 2-3 on page 87 of Marvell's latest PXA270
Specification Update Rev. I from 2010.04.19 [1] there exists a breed of
chips with a new CPU ID for PXA270M A1 stepping which our latest
Colibri PXA270 V2.4A modules actually have assembled. This patch helps
in correctly identifying those chips upon boot as well which then looks
as follows:
CPU: Marvell PXA27xM rev. A1
[1] http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_spec_update.pdf
Acked-by: Marek Vasut <marex@denx.de>
commit d9f43c8f5c sets
get_reset_cause() as static, but this conflicts with mx5
where its prototype is in sys_proto.h.
Drop it from sys_proto.h and drop print_cpuinfo from mx53_loco,
factorizing the call for this board.
Signed-off-by: Stefano Babic <sbabic@denx.de>
CC: Jason Liu <jason.hui@linaro.org>
Import DTS for Arria V development kit and enable support
for DT. The DT is imported from Linux 3.19-rc1 as of commit
97bf6af1f928216fd6c5a66e8a57bfa95a659672 .
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chin Liang See <clsee@opensource.altera.com>
Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Acked-by: Pavel Machek <pavel@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Cc: Vince Bridgers <vbridger@opensource.altera.com>
Import DTS for Cyclone V development kit and enable support
for DT. The DT is imported from Linux 3.19-rc1 as of commit
97bf6af1f928216fd6c5a66e8a57bfa95a659672 .
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chin Liang See <clsee@opensource.altera.com>
Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Acked-by: Pavel Machek <pavel@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Cc: Vince Bridgers <vbridger@opensource.altera.com>
Add support for the Altera Arria V development kit.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chin Liang See <clsee@opensource.altera.com>
Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Cc: Pavel Machek <pavel@denx.de>
Cc: Stefan Roese <sr@denx.de>
Cc: Vince Bridgers <vbridger@opensource.altera.com>
Currently in some cases SDRAM init requires global_data to be available
and soon this will not be available prior to board_init_f(). Adjust the
code paths in these cases to be correct. In some cases we had the SPL
stack be in DDR as we might have large stacks (due to Falcon Mode +
Environment). In these cases switch to CONFIG_SPL_STACK_R. In other
cases we had simply been setting CONFIG_SPL_STACK into SRAM. In these
cases we no longer need to (CONFIG_SYS_INIT_SP_ADDR is used and is also
in SRAM) so drop those lines.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested on Beagleboard, Beagleboard xM
Tested-by: Matt Porter <mporter@konsulko.com>
Tested on Beaglebone Black, AM43xx GP EVM, OMAP5 uEVM, OMAP4 Pandaboard
Tested-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present SPL uses a single stack, either CONFIG_SPL_STACK or
CONFIG_SYS_INIT_SP_ADDR. Since some SPL features (such as MMC and
environment) require a lot of stack, some boards set CONFIG_SPL_STACK to
point into SDRAM. They then set up SDRAM very early, before board_init_f(),
so that the larger stack can be used.
This is an abuse of lowlevel_init(). That function should only be used for
essential start-up code which cannot be delayed. An example of a valid use is
when only part of the SPL code is visible/executable, and the SoC must be set
up so that board_init_f() can be reached. It should not be used for SDRAM
init, console init, etc.
Add a CONFIG_SPL_STACK_R option, which allows the stack to be moved to a new
address before board_init_r() is called in SPL.
The expected SPL flow (for CONFIG_SPL_FRAMEWORK) is documented in the README.
Signed-off-by: Simon Glass <sjg@chromium.org>
For version 1:
Acked-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Bo Shen <voice.shen@atmel.com>
Acked-by: Bo Shen <voice.shen@atmel.com>
Acked-by: Heiko Schocher <hs@denx.de>
Tested-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
Use the full driver model GPIO and serial drivers in SPL now that these are
supported. Since device tree is not available they will use platform data.
Remove the special SPL GPIO function as it is no longer needed.
This is all in one commit to maintain bisectability.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is already set up in crt0.S. We don't need a new structure and don't
really want one in the 'data' section of the image, since it will be empty
and crt0.S's changes will be ignored.
As an interim measure, remove it only if CONFIG_DM is not defined. This
allows us to press ahead with driver model in SPL and allow the stragglers
to catch up.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function has grown into something of a monster. Some boards are setting
up a console and DRAM here in SPL. This requires global_data which should be
set up in one place (crt0.S).
There is no need for SPL to use s_init() for anything since board_init_f()
is called immediately afterwards.
Signed-off-by: Simon Glass <sjg@chromium.org>
This fixes the MMC/SD card detect GPIOs for Apalis T30 which got broken
by the following commit:
2b2b50bc87 "dm: tegra: dts: Use TEGRA_GPIO() macro for all GPIOs"
While at it also re-add the comments describing which particular
Apalis/Colibri pins those GPIOs are on.
Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Stefan Agner <stefan.agner@toradex.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
All boards with a SPI interface have a suitable spi alias except Apalis
T30. Add these missing aliases just as the following commit did for the
others:
d2f60f9332 "dm: tegra: dts: Add aliases for spi on tegra30 boards"
Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This patch incorporates a few fixes from Tom Warren <twarren@nvidia.com>.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Tegra210 has a per-pin option named e_io_hv, which indicates that the
pin's input path should be configured to be 3.3v-tolerant. Add support
for this.
Note that this is very similar to previous chip's rcv_sel option.
However, since the Tegra TRM names this option differently for the
different chips, we support the new name so that the code exactly matches
the naming in the TRM, to avoid confusion.
This patch incorporates a few fixes from Tom Warren <twarren@nvidia.com>.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Tegra210 starts its drive group registers at a different offset from the
APB MISC register block that other SoCs. Update the code to handle this.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
T210 support HSM and Schmitt options in the pinmux register (previous
chips placed these options in the drive group register). Update the
code to handle this.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Tegra210 moves some bits around in the pinmux registers. Update the code
to handle this.
This doesn't attempt to address the issues with the group-to-group varying
drive group register layout mentioned earlier. This patch handles the
SoC-to-SoC differences in the mux register layout.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
On some future SoCs, some per-drive-group features became per-pin
features. Move all type definitions early in the header so they can
be enabled irrespective of the setting of TEGRA_PMX_SOC_HAS_DRVGRPS.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
On some future SoCs, some of the per-drive-group features no longer
exist. Add some ifdefs to support this.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Future SoCs have a slightly different combination of pinmux options per
pin. This will be simpler to handle if we simply have one define per
option, rather than grouping various options together, in combinations
that don't align with future chips.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Tegra's drive group registers have a remarkably inconsistent layout. The
current U-Boot driver doesn't take this into account at all. Add a
comment to describe the issue, so at least anyone debugging the driver
will be aware of this. To solve this, we'd need to add a per-drive-group
data structure describing the layout for the individual register. Since
we don't set up too many drive groups in U-Boot at present, this
hopefully isn't causing too much practical issue. Still, we probably need
to fix this sometime.
Wth Tegra210, the register layout becomes almost entirely consistent, so
this problem partially solves itself over time.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This is needed to correctly apply the new Jetson TK1 pinmux config.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
When the CPU is in non-secure (NS) mode (when running U-Boot under a
secure monitor), certain actions cannot be taken, since they would need
to write to secure-only registers. One example is configuring the ARM
architectural timer's CNTFRQ register.
We could support this in one of two ways:
1) Compile twice, once for secure mode (in which case anything goes) and
once for non-secure mode (in which case certain actions are disabled).
This complicates things, since everyone needs to keep track of
different U-Boot binaries for different situations.
2) Detect NS mode at run-time, and optionally skip any impossible actions.
This has the advantage of a single U-Boot binary working in all cases.
(2) is not possible on ARM in general, since there's no architectural way
to detect secure-vs-non-secure. However, there is a Tegra-specific way to
detect this.
This patches uses that feature to detect secure vs. NS mode on Tegra, and
uses that to:
* Skip the ARM arch timer initialization.
* Set/clear an environment variable so that boot scripts can take
different action depending on which mode the CPU is in. This might be
something like:
if CPU is secure:
load secure monitor code into RAM.
boot secure monitor.
secure monitor will restart (a new copy of) U-Boot in NS mode.
else:
execute normal boot process
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Some systems have so much RAM that the end of RAM is beyond 4GB. An
example would be a Tegra124 system (where RAM starts at 2GB physical)
that has more than 2GB of RAM.
In this case, we want gd->ram_size to represent the actual RAM size, so
that the actual RAM size is passed to the OS. This is useful if the OS
implements LPAE, and can actually use the "extra" RAM.
However, we can't use get_ram_size() to verify the actual amount of RAM
present on such systems, since some of the RAM can't be accesses, which
confuses that function. Avoid calling get_ram_size() when the RAM size
is too large for it to work correctly. It's never actually needed anyway,
since there's no reason for the BCT to report the wrong RAM size.
In systems with >=4GB RAM, we still need to clip the reported RAM size
since U-Boot uses a 32-bit variable to represent the RAM size in bytes.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
size_mb is used to hold a value that's sometimes KB, sometimes MB,
and sometimes bytes. Use separate correctly named variables to avoid
confusion here. Also fix indentation of a conditional statement.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Add basic Xilinx ZynqMP arm64 support.
Serial and SD is supported.
It supports emulation platfrom ep108 and QEMU.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
With a389531 we now call readl() from this file so add <asm/io.h> so
that we have a prototype for the function.
Signed-off-by: Tom Rini <trini@konsulko.com>
Freescale's SEC block has built-in Data Encryption
Key(DEK) Blob Protocol which provides a method for
protecting a DEK for non-secure memory storage.
SEC block protects data in a data structure called
a Secret Key Blob, which provides both confidentiality
and integrity protection.
Every time the blob encapsulation is executed,
a AES-256 key is randomly generated to encrypt the DEK.
This key is encrypted with the OTP Secret key
from SoC. The resulting blob consists of the encrypted
AES-256 key, the encrypted DEK, and a 16-bit MAC.
During decapsulation, the reverse process is performed
to get back the original DEK. A caveat to the blob
decapsulation process, is that the DEK is decrypted
in secure-memory and can only be read by FSL SEC HW.
The DEK is used to decrypt data during encrypted boot.
Commands added
--------------
dek_blob - encapsulating DEK as a cryptgraphic blob
Commands Syntax
---------------
dek_blob src dst len
Encapsulate and create blob of a len-bits DEK at
address src and store the result at address dst.
Signed-off-by: Raul Cardenas <Ulises.Cardenas@freescale.com>
Signed-off-by: Nitin Garg <nitin.garg@freescale.com>
Signed-off-by: Ulises Cardenas <ulises.cardenas@freescale.com>
Signed-off-by: Ulises Cardenas-B45798 <Ulises.Cardenas@freescale.com>
Since commit 3ff46cc42b ("arm: relocate the exception vectors") mx35
does not boot anymore.
Add a specific relocate_vectors macro that skips the vector relocation, as the
i.MX35 SoC does not provide RAM at the high vectors address (0xFFFF0000), and
(0x00000000) maps to ROM.
This allows mx35 to boot again.
Cc: Sebastian Priebe <sebastian.priebe@cadcon.de>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Tested-by: Stefano Babic <sbabic@denx.de>
Since commit 3ff46cc42b ("arm: relocate the exception vectors") mx31
does not boot anymore.
Add a specific relocate_vectors macro that skips the vector relocation, as the
i.MX31 SoC does not provide RAM at the high vectors address (0xFFFF0000), and
(0x00000000) maps to ROM.
This allows mx31 to boot again.
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Magnus Lilja <lilja.magnus@gmail.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
If CONFIG_ARMV7_PSCI is not defined and CONFIG_ARMV7_SECURE_BASE is defined,
smp_kicl_all_cpus may enable secondary cores and runs into secure_ram_addr(
_smp_pen), before code is relocated to secure ram.
So need relocation to secure ram before enable secondary cores.
Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Each way of the system cache has 256 entries for PH1-Pro4 and older
SoCs, whereas 512 entries for PH1-Pro5 and newer SoCs. The line
size is still 128 byte. Thus, the way size is 32KB/64KB for old/new
SoCs.
To keep lowlevel_init SoC-independent, set BOOT_RAM_SIZE to the
constant value 32KB. It is large enough for temporary RAM and
should work for all the SoCs of UniPhier family.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
This function was intended for MN2WS0235 (what we call PH1-Pro4TV).
On that SoC, MPLL is already running on the power-on reset and it
makes sense to stop the PLL at early boot-up.
On the other hand, PH1-Pro4(R) does not have SC_MPLLOSCCTL register,
so this function has no point.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
This code is duplicated in ph1-ld4/sg_init.c and ph1-pro4/sg_init.c.
Merge the same code into a new file, memconf.c.
The helper functions no longer have to be placed in the header file.
Also, move them into memconf.c.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
