Disable internal clock by clearing the internal
clock enable bit. This bit needs to be cleared too
when we stop the SDCLK for changing the frequency
divisor. This bit should be set to zero when the
device is not using the Host controller.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
When CONFIG_API is selected with DM_ETH this
error is present:
api/api_net.c: In function 'dev_enum_net':
api/api_net.c:61:35: warning: initialization from incompatible pointer
type
struct eth_device *eth_current = eth_get_dev();
^
api/api_net.c:68:39: error: dereferencing pointer to incomplete type
memcpy(di->di_net.hwaddr, eth_current->enetaddr, 6);
^
Disable api_net functions when ETH_DM is selected.
Signed-off-by: Chris Johns <chrisj@rtems.org>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Based on:
"ARM: uniphier: use the default CONFIG_BOOTDELAY=2"
(sha1: 7c8ef0feb9)
"I do not insist on CONFIG_BOOTDELAY=3. The default value in Kconfig,
CONFIG_BOOTDELAY=2, is just fine for these boards."
Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Per Vikas' request, the problem this commit is supposed to be solving is
something he doesn't see and further this introduces additional hardware
requirements.
This reverts commit 4b2fd720a7.
Signed-off-by: Tom Rini <trini@konsulko.com>
Loading the fdt at 0xc00000 fails if the uncompressed kernel image is
greater than 12 MiB, which is quite common with modern kernels and
multiplatform defconfigs. Move fdtaddr to 0x1e00000 which is just under
the ramdiskaddr on most targets.
Signed-off-by: Scott Wood <oss@buserror.net>
Cc: Peter Tyser <ptyser@xes-inc.com>
Cc: Dirk Eibach <eibach@gdsys.de>
Cc: Andy Fleming <afleming@gmail.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Adds information regarding SPL handling validation process of main u-boot
image on power/mpc85xx and arm/layerscape platforms.
Signed-off-by: Sumit Garg <sumit.garg@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: York Sun <york.sun@nxp.com>
For mpc85xx SoCs, the core begins execution from address 0xFFFFFFFC.
In non-secure boot scenario from NAND, this address will map to CPC
configured as SRAM. But in case of secure boot, this default address
always maps to IBR (Internal Boot ROM).
The IBR code requires that the bootloader(U-boot) must lie in 0 to 3.5G
address space i.e. 0x0 - 0xDFFFFFFF.
For secure boot target from NAND, the text base for SPL is kept same as
non-secure boot target i.e. 0xFFFx_xxxx but the SPL U-boot binary will
be copied to CPC configured as SRAM with address in 0-3.5G(0xBFFC_0000)
As a the virtual and physical address of CPC would be different. The
virtual address 0xFFFx_xxxx needs to be mapped to physical address
0xBFFx_xxxx.
Create a new PBI file to configure CPC as SRAM with address 0xBFFC0000
and update DCFG SCRTACH1 register with location of Header required for
secure boot.
The changes are similar to
commit 467a40dfe3
powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041
While P3041 has a 1MB CPC and does not require SPL. On T104x, CPC
is only 256K and thus SPL framework is used.
The changes are only applicable for SPL U-Boot running out of CPC SRAM
and not the next level U-Boot loaded on DDR.
Reviewed-by: Ruchika Gupta <ruchika.gupta@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Signed-off-by: Sumit Garg <sumit.garg@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
As part of Chain of Trust for Secure boot, the SPL U-Boot will validate
the next level U-boot image. Add a new function spl_validate_uboot to
perform the validation.
Enable hardware crypto operations in SPL using SEC block.
In case of Secure Boot, PAMU is not bypassed. For allowing SEC block
access to CPC configured as SRAM, configure PAMU.
Reviewed-by: Ruchika Gupta <ruchika.gupta@nxp.com>
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Signed-off-by: Sumit Garg <sumit.garg@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: York Sun <york.sun@nxp.com>
Due to the blow up of the latest kernel size, the default gnuzip
size (8M) seems too small. The yocto kernel size I built for
mpc8315erdb board is 5294393, and it can't be boot by using the
latest u-boot. So expand gnuzip buffer for all the mpc83xx boards
to fix this issue.
Robert P. J. Day also pointed that the kernel partition on the NAND
flash is also too small, fix it at the same time.
Reported-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Robert P. J. Day has pointed that the value of SYS_MONITOR_LEN in
MPC8315ERDB.h is smaller than the u-boot.bin. This will cause the
overlap between the code of u-boot and the environment variable.
So when executing saveenv, it will corrupt the code of u-boot and
causes the board not boot. Fix this for all the mpc83xx boards by
reserving a 512K area.
Reported-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Reviewed-by: York Sun <york.sun@nxp.com>
On Tegra186, U-Boot is booted by the binary firmware as if it were a
Linux kernel. Consequently, a DTB is passed to U-Boot. Cache the address
of that DTB, and parse the /memory/reg property to determine the actual
RAM regions that U-Boot and subsequent EL2/EL1 SW may actually use.
Given the binary FW passes a DTB to U-Boot, I anticipate the suggestion
that U-Boot use that DTB as its control DTB. I don't believe that would
work well, so I do not plan to put any effort into this. By default the
FW-supplied DTB is the L4T kernel's DTB, which uses non-upstreamed DT
bindings. U-Boot aims to use only upstreamed DT bindings, or as close as
it can get. Replacing this DTB with a DTB using upstream bindings is
physically quite easy; simply replace the content of one of the GPT
partitions on the eMMC. However, the binary FW at least partially relies
on the existence/content of some nodes in the DTB, and that requires the
DTB to be written according to downstream bindings. Equally, if U-Boot
continues to use appended DTBs built from its own source tree, as it does
for all other Tegra platforms, development and deployment is much easier.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Implement a hook to allow boards to save boot-time CPU state for later
use. When U-Boot is chain-loaded by another bootloader, CPU registers may
contain useful information such as system configuration information. This
feature mirrors the equivalent ARMv7 feature.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Rev A03 of P2180 requires some PMIC programming adjustments, yet the
PMIC's own OTP has not been updated. Consequently, U-Boot must make
these changes itself.
NVIDIA's syseng team has confirmed that these changes can be enabled on
all board revisions without issue.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
IVC (Inter-VM Communication) protocol is a Tegra-specific IPC (Inter
Processor Communication) framework. Within the context of U-Boot, it is
typically used for communication between the main CPU and various
auxiliary processors. In particular, it will be used to communicate with
the BPMP (Boot and Power Management Processor) on Tegra186 in order to
manipulate clocks and reset signals.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Many files in arch/arm/mach-tegra are compiled conditionally based on
Kconfig variables, or applicable to all platforms. We can let the main
Tegra Makefile handle compiling (or not) those files to avoid each SoC-
specific Makefile needing to duplicate entries for those files. This
leaves the SoC-specific Makefiles to compile truly SoC-specific code.
In the future, we'll hopefully add Kconfig variables for all the other
files, and refactor those files, and so reduce the need for SoC-specific
Makefiles and/or ifdefs in the Makefiles.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
There are multiple versions of p2771-0000 board. There are SW visible
incompatible differences between the versions, and they are relevant to
U-Boot. Create separate "A02" and "B00" defconfigs (named after the first
and/or only board rev the defconfig supports) so that users can select
which build they want.
With the minimal set of HW currently enabled in U-Boot, the differences
are irrelevant, hence the DT files aren't different. However, that will
change in a future patch.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Tegra186 uses different GPIO port IDs compared to previous chips. Make
sure the SoC DT file includes the correct GPIO binding header.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Commit 555f45d8f9 ("image: Convert the IH_... values to enums")
accidentally changed some IH_ARCH_... values.
Prior to that commit, there existed a gap between IH_ARCH_M68K and
IH_ARCH_MICROBLAZE, like follows.
#define IH_ARCH_SPARC64 11 /* Sparc 64 Bit */
#define IH_ARCH_M68K 12 /* M68K */
#define IH_ARCH_MICROBLAZE 14 /* MicroBlaze */
#define IH_ARCH_NIOS2 15 /* Nios-II */
The enum conversion broke the compatibility with existing uImage
files. Reverting 555f45d8f9 will cause build error unfortunately,
so here is a more easy fix.
I dug the git history and figured out the gap was introduced by
commit 1117cbf2ad ("nios: remove nios-32 arch"). So, I revived
IH_ARCH_NIOS just for filling the gap.
I added comments to each enum block. Once we assign a value to
IH_... it is not allowed to change it.
Acked-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit c1ebf54868 ("imx_common: Return MMCSD_MODE_FS in spl_boot_mode()
also for EXTFS") causes SPL breakage on wandboard:
ERROR: v7_dcache_inval_range - start address is not aligned - 0x1820006c
ERROR: v7_dcache_inval_range - stop address is not aligned - 0x1820086c
ERROR: v7_dcache_inval_range - start address is not aligned - 0x1820006c
ERROR: v7_dcache_inval_range - stop address is not aligned - 0x1820086c
** First descriptor is NOT a primary desc on 0:1 **
spl: no partition table found
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
This error is seen when SPL and u-boot.img are stored in the raw SD card
partition.
This reverts commit c1ebf54868.
Signed-off-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Commit 83fd908f28 ("dm: imx: serial: Support DTE mode when using driver
model") breaks the serial output for the imx boards that do not use
the serial driver model.
The reason for the breakage is that it's setting UFCR_DCEDTE
unconditionally for the non-dm case.
So keep the original behavior by removing UFCR_DCEDTE setting in the
non-dm case.
Tested on mx7sabresd and mx6wandboard.
Signed-off-by: Breno Lima <breno.lima@nxp.com>
Acked-by: Stefan Agner <stefan.agner@toradex.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
I2C offset was changed by commit 00f792e0 (added multibus support)
from 0x3100 to 0x3000. This typo leads to error when reading SPD
from DDR DIMMs.
Signed-off-by: Benjamin Kamath <bkamath@spaceflight.com>
Signed-off-by: York Sun <york.sun@nxp.com>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
According to the IMX6DQRM Reference Manual, the description
of bit 7 (axi_alt_sel) of the CCM_CBCDR register is:
"AXI alternative clock select
0 pll2 396MHz PFD will be selected as alternative clock for AXI root clock
1 pll3 540MHz PFD will be selected as alternative clock for AXI root clock "
The current logic is inverted, so fix it to match the reference manual.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
flash_full_status_check() checks bit XSR.7 on Intel chips. This
should be done by only checking bit 7 and not by comparing the
whole status byte or word with 0x80.
This fixes the non-working block erase in the pflash emulation
of Qemu when used with the MIPS Malta board. MIPS Malta uses x32
mode to access the pflash device. In x32 mode Qemu mirrors the
lower 16 bits of the status word into the upper 16 bits. Thus
the CFI driver gets a status word of 0x8080 in x32 mode. If
flash_full_status_check() uses flash_isequal(), then it polls for
XSR.7 by comparing 0x8080 with 0x80 which never becomes true.
Reported-by: Alon Bar-Lev <alon.barlev@gmail.com>
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: Stefan Roese <sr@denx.de>
The PPA use PSCI to make secondary cores bootup. So when PPA was
enabled, add the CONFIG_ARMV8_PSCI to identify the SMP boot-method
between PSCI and spin-table.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Set the enable-method in the cpu node to PSCI, and create device
node for PSCI, when PSCI was enabled.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
If the PSCI and PPA is ready, skip the fixup for spin-table and
waking secondary cores. Otherwise, change SMP method to spin-table,
and the device node of PSCI will be removed.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
The FSL Primary Protected Application (PPA) is a software component
loaded during boot which runs in TrustZone and remains resident
after boot.
Use the secure firmware framework to integrate FSL PPA into U-Boot.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
This framework is introduced for ARMv8 secure monitor mode firmware.
The main functions of the framework are, on EL3, verify the firmware,
load it to the secure memory and jump into it, and while it returned
to U-Boot, do some necessary setups at the 'target exception level'
that is determined by the respective secure firmware.
So far, the framework support only FIT format image, and need to define
the name of which config node should be used in 'configurations' and
the name of property for the raw secure firmware image in that config.
The FIT image should be stored in Byte accessing memory, such as NOR
Flash, or else it should be copied to main memory to use this framework.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
This function assume that the d-cache and MMU has been enabled earlier,
so it just created MMU table in main memory. But the assumption is not
always correct, for example, the early setup is done in EL3, while
enable_caches() is called when the PE has turned into another EL.
Define the function mmu_setup() for fsl-layerscape to cover the weak
one.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Drop platform code to create static MMU tables. Use common framework
to create MMU tables on the run. Tested on LS2080ARDB with secure and
non-secure ram scenarios.
Signed-off-by: York Sun <york.sun@nxp.com>
This allows to overwrite reset_cpu function in case a board level
reset is preferred (e.g. through PMIC).
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Use existing Kconfig symbols to let the user configure whether to
build a U-Boot with non-secure mode support or not. This also allows
to enable virtualization extension easily.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
CONFIG_DISPLAY_BOARDINFO should not be placed in mx7_common
because some boards might need a different config such as
CONFIG_DISPLAY_BOARDINFO_LATE. Move it to the board file
instead.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
This can be useful if the same U-Boot binary is used for boards
available with a i.MX 7Solo and i.MX 7Dual.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a new config CONFIG_MXC_USB_OTG_HACTIVE which configures the
OTG Power Pin to be high active. Low active is the reset value
of the affected configuration register, hence the config option
is named by the non-reset configuration.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
USBNC_n_CTRL1 bit 9 actually controls the power pin polarity.
Rename UCTRL_PM to align reference manual and set the bit in
the appropriate callback usb_power_config.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
The MXC UART IP can be run in DTE or DCE mode. This depends on the
board wiring and the pinmux used and hence is board specific. This
extends platform data with a new field to choose wheather DTE
mode shall be used.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
It's not necessary anymore to declare the CONFIG_BOOTDELAY variable,
it's already set by default as 2 seconds.
Signed-off-by: Breno Lima <breno.lima@nxp.com>
Acked-by: Fabio Estevam <fabio.estevam@nxp.com>
The cm-fx6 module has an on-board spi flash chip. Enable mtd support
and the mtdparts command. Also define a default partitioning, add
it to the default environment, and enable support to overwrite the
partitioning defined in a device tree by it. Finally, probe for the
chip on preboot to register the flash chip and, thus, establish the
connection between the mtd environment settings and the actual device.
These changes move the effective default partitioning from the device
tree shipped with the vendor kernels to U-Boot which becomes the single
point of definition for the partitioning for all device tree based
kernels (in particular, for the upstream Linux kernel which does not
have a default partitioning defined in its device tree).
Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
Reviewed-by: Stefano Babic <sbabic@denx.de>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
The cm-fx6 module has an on-board st,m25p compatible spi flash chip
used for U-Boot (binary & environment). Overwrite the partitions in
the device tree by the partition table provided in the mtdparts
environment variable, if it is set.
This allows to specify a kernel independent partitioning in the
environment and provides a convient way for the user to adapt the
partition table.
Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Define an inline stub for fdt_fixup_mtdparts in the case that
CONFIG_FDT_FIXUP_PARTITIONS is not defined. This avoids the need
to guard every call to this function by a proper #ifdef in board
files.
Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Igor Grinberg <grinberg@compulab.co.il>
Currently, entire script segments have to be changed in the default
environment to change the kernel image location or to append kernel
cmdline parameters. In the later case this has to be changed for
every possible boot device.
Introduce new variables for kernel image locations and boot device
independent kernel parameters to make it easier to change these
settings.
Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
Reviewed-by: Igor Grinberg <grinberg@compulab.co.il>
Reviewed-by: Nikita Kiryanov <nikita@compulab.co.il>
Recently I started to notice that u-boot.img built for Wandboard
by some toolchains becomes so large that it basically overlaps with
U-Boot environment area on SD-card.
According to
http://wiki.wandboard.org/index.php/Boot-process#sdcard_boot_data_layout
Wandboard's SD-card layout is as follows:
------------------------------>8---------------------------
Acked-by: Otavio Salvador <otavio@ossystems.com.br>
Acked-by: Fabio Estevam <fabio.estevam@nxp.com>
==========================================================
1. 0x00000000 Reserved For MBR
2. 0x00000200 512 Secondary Image Table (optional)
3. 0x00000400 1024 uBoot Image (Starting From IVT)
4. 0x00060000 393216 start of uboot env (size:8k)
5. 0x00062000 end of uboot env
6. 0x00100000 1048576 Linux kernel start
7. 0x0076AC00 7777280 start of partition 1
------------------------------>8---------------------------
So for U-Boot we have 383kB (392192 bytes).
But in up to date U-Boot for Wandboard we build separately
a) SPL
b) u-boot.img
which gives us a bit more detailed SD-card layout:
------------------------------>8---------------------------
==========================================================
1. 0x00000000 Reserved For MBR
2. 0x00000200 512 Secondary Image Table (optional)
3. 0x00000400 1024 SPL
4. 0x00011400 70656 u-boot.img
5. 0x00060000 393216 start of uboot env (size:8k)
6. 0x00062000 end of uboot env
...
------------------------------>8---------------------------
>From that layout we may calculate amount of space reserved for
u-boot.img. It's just 315kb (322560 bytes).
Now if I build U-Boot with Sourcery CodeBench ARM 2014.05 produced
u-boot.img is already more than we expected
(323840 bytes instead of "< 322560"):
------------------------------>8---------------------------
ls -la u-boot.img
-rw-rw-r-- 1 user user 323840 Jul 5 07:38 u-boot.img
------------------------------>8---------------------------
Funny enough if I rebuild U-Boot with ARM toolchain available in
my Fedora 23 distro u-boot.img becomes a little bit smaller:
------------------------------>8---------------------------
ls -la u-boot.img
-rw-rw-r-- 1 user user 322216 Jul 5 07:39 u-boot.img
------------------------------>8---------------------------
What's worse this problem might not affect people most of the time
because what happens people would just copy u-boot.img on SD-card and
live in happiness with it... well until somebody attempts to save
environment in U-Boot with "saveenv" command which will simply
overwrite the very end of u-boot.img.
That will lead to unusable SD-card until user dd u-boot.img on
SD-card again.
I may foresee this issue in the future to become more visible once we
add more features in U-Boot for Wandboard or just existing code base
becomes bulkier and people will consistently get larger u-boot.img
files produced.
IMHO there's an obvious solution for all that - just move U-Boot's env
to the very end of the gap between U-Boot and the first real partition
on the SD-card. This patch will follow
8fb9eea565 ("mx6sabre_common: Fix U-Boot corruption after 'saveenv'").
So env is still not in the very end of the gap (obviously 256kb is way
too much for U-Boot's env) but at least we have now the same
partitioning for i.MX6 boards.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Otavio Salvador <otavio@ossystems.com.br>
Cc: Peter Robinson <pbrobinson@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Wolfgang Denk <wd@denx.de>