summaryrefslogtreecommitdiff
path: root/arch/arm/cpu/tegra-common/ap.c
Commit message (Collapse)AuthorAgeLines
* Add GPL-2.0+ SPDX-License-Identifier to source filesWolfgang Denk2013-07-24-17/+1
| | | | | | Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com>
* ARM: tegra: only enable SCU on Tegra20Tom Warren2013-06-06-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | The non-SPL build of U-Boot on Tegra only runs on a single CPU, and hence there is no need to enable the SCU when running U-Boot. If an SMP OS is booted, and it needs the SCU enabled, it will enable the SCU itself. U-Boot doing so is redundant. The one exception is Tegra20, where an enabled SCU is required for some aspects of PCIe to work correctly. Some Tegra SoCs contain CPUs without a software-controlled SCU. In this case, attempting to turn it on actively causes problems. This is the case for Tegra114. For example, when running Linux, the first (or at least some very early) user-space process will trigger the following kernel message: Unhandled fault: imprecise external abort (0x406) at 0x00000000 This is typically accompanied by that process receving a fatal signal, and exiting. Since this process is usually pid 1, this causes total system boot failure. Signed-off-by: Tom Warren <twarren@nvidia.com> [swarren, fleshed out description, ported to upstream chipid APIs] Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* ARM: tegra: support SKU 7 of Tegra20Stephen Warren2013-05-28-0/+1
| | | | | | | | | | Make U-Boot aware of the Tegra20 SKU 7, and treat it identically to any other Tegra20. My Whistler board has a SoC with this SKU. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* ARM: tegra: support SKU 1 of Tegra114Stephen Warren2013-05-28-0/+1
| | | | | | | | | | | | Make U-Boot aware of the Tegra114 SKU 1, and treat it identically to any other Tegra114. This value is used on (at least some) Dalmore boards with a production rather than engineering chip. Such boards are in the hands of some partners who want to use upstream U-Boot. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* Tegra: Split tegra_get_chip_type() into soc & sku funcsTom Warren2013-04-15-11/+32
| | | | | | | | | | | As suggested by Stephen Warren, use tegra_get_chip() to return the pure CHIPID for a Tegra SoC (i.e. 0x20 for Tegra20, 0x30 for Tegra30, etc.) and rename tegra_get_chip_type() to reflect its true function, i.e. tegra_get_chip_sku(), which returns an ID like TEGRA_SOC_T25, TEGRA_SOC_T33, etc. Signed-off-by: Tom Warren <twarren@nvidia.com> Reviewed-by: Stephen Warren <swarren@nvidia.com>
* Tegra: Configure L2 cache control reg properly.Tom Warren2013-04-15-7/+2
| | | | | | | | | | Without this change, kernel fails at calling function cache_clean_flush during kernel early boot. Aprocryphally, intended for T114 only, so I check for a T114 SoC. Works (i.e. dalmore 3.8 kernel now starts printing to console). Signed-off-by: Tom Warren <twarren@nvidia.com>
* ARM: tegra: support T33 SKU of Tegra30Stephen Warren2013-04-15-0/+1
| | | | | | | | | | | | | | | | | | | Make U-Boot aware of the T33 SKU of Tegra30, and treat it identically to any other Tegra30. An alternative would be to simply remove the SKU checking from tegra_get_chip_type(); most use of the value most likely simply wants to know the current chip, not the specific SKU. Or, the function could be split into separate tegra_get_chip() and tegra_get_sku() for the cases where differentiation really is required. I wonder whether tegra_get_chip_type() should printf() whenever any unkown chip/SKU is found, although perhaps the function is called so early that the printf() wouldn't actually make it to the UART anyway. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org>
* Tegra114: Add common CPU (shared) filesTom Warren2013-02-11-1/+8
| | | | | | These files are used by both SPL and main U-Boot. Signed-off-by: Tom Warren <twarren@nvidia.com>
* Tegra30: Add common CPU (shared) filesTom Warren2013-01-16-2/+12
| | | | | | | | | These files are used by both SPL and main U-Boot. Also made minor changes to shared Tegra code to support T30 differences. Signed-off-by: Tom Warren <twarren@nvidia.com> Reviewed-by: Stephen Warren <swarren@nvidia.com>
* Tegra20: Move some include files to arch-tegra for sharing with Tegra30Tom Warren2012-10-15-6/+6
| | | | | | | | | | | The move is pretty straight-forward. ap20.h and tegra20.h were renamed to ap.h and tegra.h. Some files remain in arch-tegra20 but 'include' a file in 'arch-tegra' with #defines & structs that will be common between T20 and T30 HW. HW-specific #defines, etc. stay in the 'arch-tegra20' 'root' file. All boards build OK w/MAKEALL -s tegra20. Checkpatch.pl runs clean. Seaboard works OK. Signed-off-by: Tom Warren <twarren@nvidia.com>
* Tegra20: Move some code files to common directories for upcoming Tegra30 ↵Tom Warren2012-10-15-0/+131
patches. Move files that are going to be common between T20 and T30 into 'tegra-common' subdirs in AVP (arm720t), CPU (armv7), and shared (arch/arm/cpu/.) areas. Any files that are left behind in '/tegra20' will be copied to '/tegra30' subdirs and modified for that SoC. The 'common' files should need only minor changes. Include files (arch/arm/include/asm/arch-tegra/tegra20) will be done in a follow-on patch. Builds fine w/MAKEALL -s tegra20. Checkpatch.pl is clean. Signed-off-by: Tom Warren <twarren@nvidia.com>