There was for long time no activity in the mpx5xxx area.
We need to go further and convert to Kconfig, but it
turned out, nobody is interested anymore in mpc5xxx,
so remove it.
Signed-off-by: Heiko Schocher <hs@denx.de>
Secure boot targets that can be loaded from an SD card FAT partition
need to be called "MLO" on the filesystem, make a copy with this name
to clarify the correct image for SD card booting.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
NanoPi NEO2 is designed and developed by FriendlyElec
using the Allwinner 64-bit H5 SOC.
NanoPi Neo2 key features
- Allwinner H5, Quad-core 64-bit Cortex-A53
- 512MB DDR3 RAM
- microSD slot
- 10/100/1000M Ethernet
- Serial Debug Port
- 5V 2A DC MicroUSB power-supply
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
It turns out this change was not intended to be merged and as such,
revert it.
This reverts commit cdde7de036.
Reported-by: Manfred Schlaegl <manfred.schlaegl@ginzinger.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Orangepi Win/WinPlus is an open-source single-board computer
using the Allwinner A64 SOC.
A64 Orangepi Win/WinPlus has
- A64 Quad-core Cortex-A53 64bit
- 1GB(Win)/2GB(Win Plus) DDR3 SDRAM
- Debug TTL UART
- Four USB 2.0
- HDMI
- LCD
- Audio and MIC
- Wifi + BT
- IR receiver
- 5V DC power supply
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
Orangepi Zero Plus 2 is an open-source single-board computer
using the Allwinner h5 SOC.
H5 Orangepi Zero Plus 2 has
- Quad-core Cortex-A53
- 512MB DDR3
- micrSD slot and 8GB eMMC
- Debug TTL UART
- HDMI
- Wifi + BT
- OTG+power supply
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
Whistler is an ancient Tegra 2 reference board. I may have been the only
person who ever used it with upstream software, and I've just recycled
the board hardware. Hence, it makes sense to remove support from software.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
With Davinci I2C switching to device model, K2HK requires U-boot specific
device tree entries. This is only required for I2C 1 which is needed
extremely early during the boot process.
Fixes: 1743d040b1 ("ARM: keystone: Enable DM_I2C by default")
Reported-by: Yan Liu <yan-liu@ti.com>
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Create exception stack in IRAM if available to facilitate debugging of
pre-relocation code by catching exceptions rather than stopping dead.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Adjust the program counter register to point to the failing
instruction depending on the exeption type.
This makes it easier to localize the offending instruction leading to
a fatal exception.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
The cp_delay() function was introduced because of a missing 'volatile'
attribute to the 'asm' statement in get_cr() which led to the 'mrc'
instruction in get_cr() being optimised out eventually.
This has been fixed in commit 53fd4b8c22 ("arm: mmu: Add missing volatile for reading SCTLR register")
but the bogus cp_delay() function which was introduced as a workaround
for the malfunctioning get_cr() was never removed.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
stm32x7.c driver is dedicated for STM32F7.
In kernel, "st,stm32-usart" and "st,stm32-uart" compatible
strings are dedicated for STM32F4.
To keep U-boot and kernel aligned, replace the serial compatible
string from "st,stm32-usart", "st,stm32-uart" to
"st,stm32f7-usart", "st,stm32f7-uart" specific for STM32F7.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Christophe KERELLO <christophe.kerello@st.com>
Reviewed-by: Patrick DELAUNAY <patrick.delaunay@st.com>
Acked-by: Vikas MANOCHA <vikas.manocha@st.com>
There was for long time no activity in the 5xx area.
We need to go further and convert to Kconfig, but it
turned out, nobody is interested anymore in 5xx,
so remove it.
Signed-off-by: Heiko Schocher <hs@denx.de>
There was for long time no activity in the 8260 area.
We need to go further and convert to Kconfig, but it
turned out, nobody is interested anymore in 8260,
so remove it.
Signed-off-by: Heiko Schocher <hs@denx.de>
There was for long time no activity in the 8xx area.
We need to go further and convert to Kconfig, but it
turned out, nobody is interested anymore in 8xx,
so remove it (with a heavy heart, knowing that I remove
here the root of U-Boot).
Signed-off-by: Heiko Schocher <hs@denx.de>
This patch reuses new option, which allows us to expose variables
from environment to "fastboot getvar" command. Those variables must be
of "fastboot.%s" format.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Using u-boot-2017.05 on i.MX6UL we ran into following problem:
Initially U-Boot could be started normally.
If we added one random command in configuration, the newly generated
image hung at startup (last output was DRAM: 256 MiB).
We tracked this down to a data abort within relocation (relocated_code).
relocated_code in arch/arm/lib/relocate.S copies 8 bytes per loop
iteration until the source pointer is equal to __image_copy_end.
In a good case __image_copy_end was aligned to 8 bytes, so the loop
stopped as suggested, but in an errornous case __image_copy_end was
not aligned to 8 bytes, so the loop ran out of bounds and caused a
data abort exception.
This patches solves the issue by aligning __image_copy_end to 8 byte
using the linker script related to arm.
I don't know if it's the correct way to solve this, so some review would
be very appreciated.
Currently we set the entry address in the psci_cpu_on function.
However R40 has a different register for this. This resulted in
an #ifdef / #else block in psci_cpu_on, which we avoided having
in the first place.
Move this part into a separate function, defined differently for
the R40 as opposed to the other single cluster platforms.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Disable D-Cache is required when booting nommu Linux kernel.
(please see Linux kernel source "arch/arm/kernel/head-nommu.S")
U-Boot is enabled D-cache and I-Cache at startup.
However, it does not disable D-Cache before
booting nommu Linux kernel.
Therefore, I call dcache_disable()
when the CPU is ARMv7M to fix this problem.
Signed-off-by: Toshifumi NISHINAGA <tnishinaga.dev@gmail.com>
Refactor OMAP3/4/5 code so that we have only one get_device_type()
function for all platforms.
Details:
- Add ctrl variable for AM33xx and OMAP3 platforms (like it's done for
OMAP4/5), so we can obtain status register in common way
- For now ctrl structure for AM33xx/OMAP3 contains only status register
address
- Run hw_data_init() in order to assign ctrl to proper structure
- Remove DEVICE_MASK and DEVICE_GP definitions as they are not used
(DEVICE_TYPE_MASK and GP_DEVICE are used instead)
- Guard structs in omap_common.h with #ifdefs, because otherwise
including omap_common.h on non-omap4/5 board files breaks compilation
Buildman script was run for all OMAP boards. Result output:
arm: (for 38/616 boards)
all +352.5
bss -1.4
data +3.5
rodata +300.0
spl/u-boot-spl:all +284.7
spl/u-boot-spl:data +2.2
spl/u-boot-spl:rodata +252.0
spl/u-boot-spl:text +30.5
text +50.4
(no errors to report)
Tested on AM57x EVM and BeagleBoard xM.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
[trini: Rework the guards as to not break TI81xx]
Signed-off-by: Tom Rini <trini@konsulko.com>
Almost all users of CONFIG_AM33XX/AM43XX have been migrated. Finish
moving the last few over to Kconfig, and put all of the boards under the
appropriate Kconfig chocie now. This board choice is non-optional, so
remove that keyword on am33xx.
Signed-off-by: Tom Rini <trini@konsulko.com>
If U-Boot is chain-loaded from a previous boot loader we must set up the
clocks the way U-Boot wants them. Add code for this. It will do nothing if
SPL has already done the job.
Signed-off-by: Simon Glass <sjg@chromium.org>
Shifted masks are the standard approach with rockchip since it allows
use of the mask without shifting it each time. Update the definitions and
the driver to match.
Signed-off-by: Simon Glass <sjg@chromium.org>
The clock fix-up for tegra is still present in the code. It causes a
divide-by-zero bug after relocation when chain-loading U-Boot from
coreboot. Fix this by adding a check.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 7468676 (ARM: tegra: fix clock_get_periph_rate() for UART clocks)
At present the interrupt does not work and the SPI bus runs much less
quickly than it should. Add settings to fix this.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present early clock init happens in SPL. If SPL did not run (because
for example U-Boot is chain-loaded from another boot loader) then the
clocks are not set as U-Boot expects.
Add a function to detect this and call the early clock init in U-Boot
proper.
Signed-off-by: Simon Glass <sjg@chromium.org>
If CONFIG_ARMV7_LPAE is not defined we should make sure that the feature
is disabled. This can happen if U-Boot is chain-loaded from another boot
loader which does enable LPAE.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present if CONFIG_ARMV7_LPAE is defined then mmu_setup() will use
instructions which are invalid on ARMv4T. This happens on Tegra since it
has an ARMv4T boot CPU. Add a check for the architecture version to allow
the code to be built. It will not actually be executed by the boot CPU,
but needs to compile.
Signed-off-by: Simon Glass <sjg@chromium.org>
This option allows skipping the call to lowlevel() while still performing
CP15 init. Support this on ARM720T so it can be used with Tegra.
Signed-off-by: Simon Glass <sjg@chromium.org>
With xip booting configuration, we don't need to copy the next image
(U-Boot or linux xipimage) from flash to sdram area.
Flash memory organization is like this:
spl-U-Boot: u-boot-spl.bin : 0x0800_0000
U-Boot : u-boot-dtb.bin : 0x0800_8000
linux : xipImage : 0x0800_8000
It is also possible to have U-Boot binary & linux binaries configured at
different addresses of flash memory like U-Boot at 0x0800_8000 & linux
xipImage at 0x0800_4000. But in any case, spl-U-Boot needs to be compiled for
U-Boot as next binary with SPL_OS_BOOT option disabled.
By default, spl is configured to boot linux xipImage.
Signed-off-by: Vikas Manocha <vikas.manocha@st.com>
Enable support for XIP (execute in place) of U-Boot or kernel image. There is
no need to copy image from flash to ram if flash supports execute in place.
Signed-off-by: Vikas Manocha <vikas.manocha@st.com>
Reviewed-by: Alexandru Gagniuc <alex.g@adaptrum.com>
This commit supports booting from stm32 internal nor flash. spl U-Boot
initializes the sdram memory, copies next image (e.g. standard U-Boot)
to sdram & then jumps to entry point.
Here are the flash memory addresses for U-Boot-spl & standard U-Boot:
- spl U-Boot : 0x0800_0000
- standard U-Boot : 0x0800_8000
To compile u-boot without spl: Remove SUPPORT_SPL configuration
(arch/arm/mach-stm32/Kconfig)
Signed-off-by: Vikas Manocha <vikas.manocha@st.com>
[trini: Rework Kconfig logic a bit]
Signed-off-by: Tom Rini <trini@konsulko.com>
Extend DE2 driver with support for TVE driver, which will be added in
next commit. TVE unit expects data to be in YUV format, so CSC support
is also added here.
Note that HDMI driver has higher priority, so TV out is not probed if
HDMI monitor is detected.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This commit adds TVE base address for Allwinner H3 and H5 SoCs.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
In os_dirent_get_typename() we are checking that type falls within the
known values of the enum os_dirent_t. With clang-3.8 testing this value
as being >= 0 results in a warning as it will always be true. This
assumes of course that we are only given valid data. Given that we want
to sanity check the input, we change this to check that it falls within
the range of the first to the last entry in the given enum.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
As we added LPDDR3 support in the former patch, we need a set of timing
info to really enable it.
Add the timing info used by stock boot0.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Acked-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
Some A64 boards (SoPine and Pinebook production batch) use LPDDR3 DRAM
chips.
Add support for LPDDR3 DRAM in the DesignWare-like DRAM controller code.
Real LPDDR3 chips' support is not added yet in this commit.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
As we have already support for the DesignWare DRAM controller and the
integrated DDR2 chip of V3s, let's enable the SPL support for V3s.
This patch also contains the default DRAM configuration for V3s.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
Allwinner V3s features a DRAM controller like the on in H3, but with a
DDR2 DRAM.
Add support for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
Allwinner V3s SoC features a co-packaged DDR2 DRAM chip, which needs its
timing param.
Add support for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Acked-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
The DesignWare-like DRAM code used to set the controller defaultly to
single rank mode, which makes it not able to detect the second rank.
Set the default value to dual rank, thus the rank detection code can
work and finally the rank setting will be the correct value.
Currently we know little about the dual-rank on R40, and the usage
of A15 address line seems to be breaking dual-rank support. The only R40
board currently available (Sinovoip Banana Pi M2 Ultra) uses A15 rather
than dual-rank, thus we cannot do research for it. So dual rank detection
is temporarily disabled on R40.
This change is tested on a Orange Pi One (H3, single rank), a Pine64+
2GiB version (A64, single rank) , a Pinebook early prototype with DDR3
(A64, dual rank) and a SoPine with some LPDDR3 patch (A64, dual CS pins
on one chip).
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
DRAM chip varies, and one code cannot satisfy all DRAMs.
Add options to select a timing set.
Currently only DDR3-1333 (the original set) is added into it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
Heiko Schocher
Andrew F. Davis
Masahiro Yamada
Jagan Teki
Tom Rini
Stephen Warren
York Sun
Cooper Jr., Franklin
Lothar Waßmann
Patrice Chotard
Semen Protsenko
Manfred Schlaegl
Chen-Yu Tsai
tnishinaga.dev@gmail.com
Simon Glass
Vikas Manocha
Jernej Skrabec
Kouei Abe
Icenowy Zheng
Icenowy Zheng