| Age | Commit message (Collapse) | Author |
|---|
|
Support PSCI and switch to non-secure mode when booting linux.
Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
Signed-off-by: Frank Li <Frank.Li@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
|
|
1. add basic psci support for imx7 chip.
2. support cpu_on and cpu_off.
3. switch to non-secure mode when boot linux kernel.
4. set csu allow accessing all peripherial register in non-secure mode.
Signed-off-by: Frank Li <Frank.Li@freescale.com>
Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
|
|
The code such as PSCI in section named secure is bundled with
u-boot image, and when bootm, the code will be copied to their
runtime address same to compliation/linking address -
CONFIG_ARMV7_SECURE_BASE.
When compile the PSCI code and link it into the u-boot image,
there will be relocation entries in .rel.dyn section for PSCI.
Actually, we do not needs these relocation entries.
If still keep the relocation entries in .rel.dyn section,
r0 at line 103 and 106 in arch/arm/lib/relocate.S may be an invalid
address which may not support read/write for one SoC.
102 /* relative fix: increase location by offset */
103 add r0, r0, r4
104 ldr r1, [r0]
105 add r1, r1, r4
106 str r1, [r0]
So discard them to avoid touching the relocation entry in
arch/arm/lib/relocate.S.
Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
Cc: Tom Warren <twarren@nvidia.com>
Cc: York Sun <yorksun@freescale.com>
Cc: Hans De Goede <hdegoede@redhat.com>
Cc: Ian Campbell <ijc@hellion.org.uk>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Tom Rini <trini@konsulko.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Stefano Babic <sbabic@denx.de>
Acked-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
|
|
p2371-2180 is the engineering board name for the Jetson TX1 developer
kit. Update Kconfig description and help text to make this obvious to
everyone.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
There is really no need to provide an empty reset_cpu() implementation,
so just remove it.
Cc: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Tim Harvey <tharvey@gateworks.com>
|
|
There is really no need to provide an empty reset_cpu() implementation,
so just remove it.
Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Christian Gmeiner <christian.gmeiner@gmail.com>
|
|
There is really no need to provide an empty reset_cpu() implementation,
so just remove it.
Cc: Marek Vasut <marex@denx.de>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Marek Vasut <marex@denx.de>
|
|
There is really no need to provide an empty reset_cpu() implementation,
so just remove it.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
|
|
There is really no need to provide an empty reset_cpu() implementation,
so just remove it.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
|
|
There is really no need to provide an empty reset_cpu() implementation,
so just remove it.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
|
|
There is really no need to provide an empty reset_cpu() implementation,
so just remove it.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Reviewed-by: Stefano Babic <sbabic@denx.de>
|
|
This allows for more flexible and standardized boot across multiple
platforms.
Remove redundant legacy boot environment.
Cc: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Vagrant Cascadian <vagrant@debian.org>
|
|
This allows for more flexible and standardized boot across multiple
platforms.
Remove redundant legacy boot environment.
Signed-off-by: Vagrant Cascadian <vagrant@debian.org>
|
|
This is the normal Tegra SPI driver modified to work with the
QSPI controller in Tegra210. It does not do 2x/4x transfers
or any other QSPI protocol.
Signed-off-by: Yen Lin <yelin@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>
|
|
Rename GPU functions to less generic names to avoid potential name
collisions.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
Enable the GPU node in the system-wide ft_system_setup() hook instead of
the board-specific ft_board_hook(). This allows us to enable GPU per SoC
generation instead of per-board as we did initially.
Reported-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
There is no justification for this function, especially in exported
form.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
Add code to detect timeouts when waiting for HW events such as PLL
lock done. Any errors are logged and trigger an error return code.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
Add the tables defining which pads and mux options exist in the Tegra210
XUSB padctl hardware.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
This change simply deletes code from the Tegra210 XUSB padctl driver that
is already present in the common XUSB padctl code. Since all the arrays
in tegra210_socdata are empty, this update may leave the Tegra210 XUSB
padctl driver non-functional at run-time. However, (a) this driver is not
used yet so no regression can be observed and (b) the next commit will
immediately fix this up.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
There are some differences between the Tegra124 and Tegra210 XUSB padctl
code. So far, the common XUSB padctl code only supports Tegra124. Add
some parameters etc. so that it can work for both chips.
This also allows moving Tegra124's process_nodes() into the common file;
something that would have requires edits during the move if done in the
previous commit.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
A fair amount of the XUSB padctl driver will be common between Tegra124
and Tegra210. To avoid cut/paste between the two chips, create a new
file that will contain the common code, and convert the Tegra124 code to
use it. This change doesn't move every last piece of code that can/will be
shared, but rather concentrates on moving code that can be moved with zero
changes, so there are no other diffs mixed in.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
This file defines pr_fmt(), so the individual error() calls don't need to
include the prefix in their format strings. Doing so results in duplicate
text in any error messages. Remove the duplication.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
A future patch will soon move some of the XUSB padctl code into a common
file in arch/arm/mach-tegra. Rename the existing dummy XUSB padctl file
to avoid conflicting with that, or being confusing.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
p2371-2180 has two PCI ports; a regular x4 slot and a x1 M.2 slot. This
patch adds the relevant DT to enable the PCI controller and configure
the XUSB padctl pin muxing, and code to turn on the PCI power and enable
PCI features in U-Boot. I have only tested the x4 slot.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
Tegra210's PCI controller is largely identical to Tegra124, and hence
shares the same binding. However, it has a unique compatible value due
to the existence of at least one new HW bug that would prevent any driver
for a previous HW version from operating correctly.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
This needs a separate compatible value from Tegra124 since the new HW
version has bugs that would prevent a driver for previous HW versions
from operating at all.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
The board PCI setup code may control regulators that are required simply
to bring up the PCI controller itself (or PLLs, IOs, ... it uses). Move
the call to this function earlier so that all board-provided resources
are ready early enough for everything to work.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
Tegra210's PCIe controller has a bug that requires the PCA (performance
counter) feature to be enabled. If this isn't done, accesses to device
configuration space will hang the chip for tens of seconds. Implement
the workaround.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
The number of cells used by each entry in the DT ranges property is
determined by the #address-cells/#size-cells properties. Fix the code
to respect this.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
Tegra peripherals can generally access a 32-bit physical address space,
and I believe this applies to PCIe. Clip the PCI region that refers to
DRAM so it fits into 32-bits to avoid issues.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
Implement the procedure that the TRM mandates to initialize PLLREFE and
PLLE. This makes the PLL actually lock.
Note that this section of the TRM is being cleaned up to remove some
confusion. The set of register accesses in this patch should be final,
although the step numbers/descriptions might still change.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
On the target board:
=> dfu 0 mmc 0
On the host PC:
$ dfu-util -l
Found DFU: [0525:a4a5] devnum=0, cfg=1, intf=0, alt=0, name="image"
Found DFU: [0525:a4a5] devnum=0, cfg=1, intf=0, alt=1, name="u-boot"
Found DFU: [0525:a4a5] devnum=0, cfg=1, intf=0, alt=2, name="bootimg"
Found DFU: [0525:a4a5] devnum=0, cfg=1, intf=0, alt=3, name="rootfs"
Update with a full SD image
$ dfu-util -a image -D core-image-minimal-imx7dsabresd.sdcard
Update u-boot only
$ dfu-util -a u-boot -D u-boot.imx
Signed-off-by: Tzu-Jung Lee <roylee17@currantlabs.com>
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
|
|
|
|
|
|
Add 3c120 and 10m50 devboards MAINTAINERS
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Acked-by: Marek Vasut <marex@denx.de>
|
|
The 10m50 devboard becomes the new golden reference design of
Nios II Linux. So change README.nios2 to use 10m50 as template.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Acked-by: Marek Vasut <marex@denx.de>
|
|
Rename board nios2-generic to 3c120_devboard. Since nios2 is
converted to driver model and device tree control of u-boot,
the nios2-generic board directory is removed. We can rename
the board back to a real board name. Now the boards maintained
in u-boot mainline are the same as Linux kernel, namely 3c120
and 10m50.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Marek Vasut <marex@denx.de>
|
|
Add 10m50 devboard support. It is based on the Golden Hardware
Reference Design (GHRD), available at,
http://rocketboards.org/foswiki/view/Documentation/
AlteraMAX1010M50RevCDevelopmentKitLinuxSetup
Though we supported only one nios2-generic board in the past. Now,
with the removal of the nios2-generic board dir, adding new nios2
boards to u-boot is easier than before. It should be helpful to
add those boards supported in Linux mainline. There are only two
such nios2 boards, the 3c120 devboard and 10m50 devboard. The
nios2-generic is actually 3c120, and should restore the name. The
10m50 is this one.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Marek Vasut <marex@denx.de>
|
|
The Modular Scatter-Gather DMA core is a new DMA core to work
with the Altera Triple-Speed Ethernet MegaCore. It replaces the
legacy Scatter-Gather Direct Memory Access (SG-DMA) controller
core. Please find details on the "Embedded Peripherals IP User
Guide" of Altera.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Marek Vasut <marex@denx.de>
|
|
Add priv ops to prepare msgdma support. These ops are dma type
specific.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Marek Vasut <marex@denx.de>
|
|
Move the sgdma wait from free_pkt to recv. This is the proper
place to wait recv sgdma done.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Marek Vasut <marex@denx.de>
|
|
Factor out the stop mac function to prepare msgdma support.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Marek Vasut <marex@denx.de>
|
|
Zap the altera_tse_initialize() prototypes, since it is converted
to driver model.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Marek Vasut <marex@denx.de>
|
|
Do not allocate rx buf in net.c, because altera_tse allocates
its own rx buf in driver. This can save 6KB memory.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
|
|
Add Altera Generic Quad SPI Controller support. The controller
converts SPI NOR flash to parallel flash interface. So it is
not like other SPI flash, but rather like CFI flash.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
|
|
Add memcpy_fromio() and memcpy_toio().
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
|
|
Use cfi flash driver model.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
|
|
Convert cfi flash to driver model.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Implement a Memory Technology Device (MTD) uclass. It should
include most flash drivers in the future. Though no uclass ops
are defined yet, the MTD ops could be used.
The NAND flash driver is based on MTD. The CFI flash and SPI
flash support MTD, too. It should make sense to convert them
to MTD uclass.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
|
