summaryrefslogtreecommitdiff
path: root/arch
Commit message (Collapse)AuthorAgeLines
...
* | arm: socfpga: reset: Add SDMMC, QSPI and DMA definesMarek Vasut2015-08-08-0/+3
| | | | | | | | | | | | | | Add SDMMC, QSPI and DMA reset defines. These are needed by SPL so that we can boot from SD card and QSPI. Signed-off-by: Marek Vasut <marex@denx.de>
* | arm: socfpga: reset: Add function to reset add peripheralsMarek Vasut2015-08-08-0/+14
| | | | | | | | | | | | | | Add socfpga_per_reset_all() function to reset all peripherals but the L4 watchdog. This is needed in the SPL. Signed-off-by: Marek Vasut <marex@denx.de>
* | arm: socfpga: reset: Repair bridge reset handlingMarek Vasut2015-08-08-4/+4
| | | | | | | | | | | | | | | | | | | | | | The current bridge reset code, which de-asserted the bridge reset, was activelly polling whether the FPGA is programmed and ready and in case it was (!), the code called hang(). This makes no sense at all. Repair it such that the code instead checks whether the FPGA is programmed, but without any polling involved, and only if it is programmed, it de-asserts the reset. Signed-off-by: Marek Vasut <marex@denx.de>
* | arm: socfpga: reset: Replace ad-hoc reset functionsMarek Vasut2015-08-08-64/+13
| | | | | | | | | | | | | | | | Replace all those ad-hoc reset functions, which were all copies of the same invocation of clrbits_le32() anyway, with one single unified function, socfpga_per_reset(), with necessary parameters. Signed-off-by: Marek Vasut <marex@denx.de>
* | arm: socfpga: reset: Implement unified function to toggle resetMarek Vasut2015-08-08-23/+37
| | | | | | | | | | | | | | | | Implement function socfpga_per_reset(), which allows asserting or de-asserting reset of each reset manager peripheral in a unified manner. Use this function throughout reset manager. Signed-off-by: Marek Vasut <marex@denx.de>
* | arm: socfpga: reset: Start reworking the SoCFPGA reset managerMarek Vasut2015-08-08-19/+50
| | | | | | | | | | | | | | | | | | | | Implement macro SOCFPGA_RESET(name), which produces an abstract reset number. Implement macros which allow extracting the reset offset in permodrstN register and which permodrstN register the reset is located in from this abstract reset number. Use these macros throughout the reset manager. Signed-off-by: Marek Vasut <marex@denx.de>
* | arm: socfpga: reset: Add missing reset manager regsMarek Vasut2015-08-08-0/+2
| | | | | | | | | | | | | | Define two missing reset manager registers, which are in the SoCFPGA CV datasheet. Signed-off-by: Marek Vasut <marex@denx.de>
* | ddr: altera: Move struct sdram_prot_rule prototypeMarek Vasut2015-08-08-13/+0
| | | | | | | | | | | | | | | | | | | | | | Move the structure prototype from sdram.h header file into sdram.c source file, since it is used only there and for local purpose only. There is no point in having it global. While at this move, fix the data types in the structure from uintNN_t to uNN and fix the coding style a bit. Signed-off-by: Marek Vasut <marex@denx.de>
* | arm: socfpga: Move sdram_config.h to board dirMarek Vasut2015-08-08-100/+0
| | | | | | | | | | | | | | This file is absolutelly positively board specific, so move it into the correct place. Signed-off-by: Marek Vasut <marex@denx.de>
* | driver/ddr/altera: Add DDR driver for Altera's SDRAM controllerDinh Nguyen2015-08-08-12/+399
| | | | | | | | | | | | | | | | This patch enables the SDRAM controller that is used on Altera's SoCFPGA family. This patch configures the SDRAM controller based on a configuration file that is generated from the Quartus tool, sdram_config.h. Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
* | arm: dts: socfpga: Add mmc aliasMarek Vasut2015-08-08-0/+1
| | | | | | | | | | | | | | Add alias for the SD/MMC controller, so it can be located by U-Boot OF support. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
* | arm: dts: socfpga: Fix SPI aliasesMarek Vasut2015-08-08-16/+5
|/ | | | | | | | | | | | | The SPI aliases are completely wrong. First, they point to non-existing /spi@.* nodes instead of the correct /soc/spi@.* nodes. Second, the use ad-hoc string instead of a handle. Furthermore, they are copied multiple times in each board DTS. So fix it such that we move these into socfpga.dtsi and make them use the usual handles. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
* Merge git://git.denx.de/u-boot-dmTom Rini2015-08-06-239/+1563
|\
| * exynos: dts: Correct LDO and BUCK namingSimon Glass2015-08-06-63/+63
| | | | | | | | | | | | | | | | At present lower case is used for the regulator names in the device tree. The kernel uses upper case and U-Boot will require this also since it will move to a case-sensitive name check. Signed-off-by: Simon Glass <sjg@chromium.org>
| * x86: Enable debug UART for MinnowmaxSimon Glass2015-08-06-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enable the debug UART and emit a single 'a' early in the init sequence to show that it is working. Unfortunately the debug UART implementation needs a stack to work. I cannot seem to remove this limitation as the absolute 'jmp %eax' instruction goes off into the weeds. So this means that the character output cannot be any earlier than car_init_ret, where memory is available for a stack. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
| * exynos: Add support for springSimon Glass2015-08-05-0/+595
| | | | | | | | | | | | | | | | | | | | Spring is the first ARM-based HP Chromebook 11. It is similar to snow and it uses the same Samsung Exynos5250 chip. But has some unusual features. Mainline support for it has lagged snow (both in kernel and U-Boot). Now that the exynos5 code is common we can support spring just by adding a device tree and a few lines of configuration. Signed-off-by: Simon Glass <sjg@chromium.org>
| * exynos: video: Remove non-device-tree codeSimon Glass2015-08-05-2/+0
| | | | | | | | | | | | We always use device tree on exynos, so remove the unused code. Signed-off-by: Simon Glass <sjg@chromium.org>
| * exynos: dts: Drop the old TPS65090 I2C nodeSimon Glass2015-08-05-16/+0
| | | | | | | | | | | | | | | | While the AP can access the main PMIC on snow, it must coordinate with the EC which also wants access. Drop the old definition, which can in principle generate collision errors. We will use the new arbitration driver instead. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dts: exynos: snow: Add a new node for the NXP video bridge driverSimon Glass2015-08-05-20/+16
| | | | | | | | | | | | The driver supports driver model. Add a node for snow, which needs it. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dts: exynos: pit: Add a new node for the parade video bridge driverSimon Glass2015-08-05-5/+123
| | | | | | | | | | | | | | The new driver supports driver model and configuration via device tree. Add a node for pit, which needs this driver. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dts: exynos: snow: Add memory layout descriptionSimon Glass2015-08-05-0/+53
| | | | | | | | | | | | | | Add a description of the snow memory layout to assist flashing tools which want to be able to deal with any exynos image. Signed-off-by: Simon Glass <sjg@chromium.org>
| * exynos: Tidy up CPU frequency displaySimon Glass2015-08-05-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Line up the display with the line below, e.g.: CPU: Exynos5250 @ 1.7 GHz Model: Google Spring DRAM: 2 GiB MMC: EXYNOS DWMMC: 0 Also show the speed as GHz where appropriate. Signed-off-by: Simon Glass <sjg@chromium.org>
| * exynos: Add support for the DisplayPort hotplug detectSimon Glass2015-08-05-0/+11
| | | | | | | | | | | | Allow this function to be selected using the pinmux API. Signed-off-by: Simon Glass <sjg@chromium.org>
| * exynos: Enable the debug UART in SPLSimon Glass2015-08-05-0/+5
| | | | | | | | | | | | | | | | As a debugging aid, allow UART3 to be used as a debug UART in SPL. This is a precursor to proper UART support, which requires a substantial refactor. Signed-off-by: Simon Glass <sjg@chromium.org>
| * exynos: dts: Support EC tunnel and main TPS65090 regulatorSimon Glass2015-08-05-48/+297
| | | | | | | | | | | | | | | | | | On pit and pi the TPS65090 regulator is connected only to the EC and we must use a tunnel to get to it. The existing U-Boot support relies on a special driver. Add a tunnel definition so that the new device-model TPS65090 driver can be used unmodified. Signed-off-by: Simon Glass <sjg@chromium.org>
| * exynos: dts: Add PMIC and regulator definitionsSimon Glass2015-08-05-0/+304
| | | | | | | | | | | | | | | | Snow and smdk5250 use a max77686 PMIC. We have a driver for this, so add the relevant node to the device tree so it can be used. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>
| * exynos: dts: Sync up I2C ports with the kernelSimon Glass2015-08-05-89/+94
| | | | | | | | | | | | | | | | The kernel uses upper case for I2C unit addresses. Follow the same convention to reduce differences. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Przemyslaw Marczak <p.marczak@samsung.com>
* | ARM: tegra: Add p2371-0000 boardStephen Warren2015-08-06-0/+69
| | | | | | | | | | | | | | | | | | | | | | P2371-0000 is a P2581 or P2530 CPU board married to a P2595 I/O board. The combination contains SoC, DRAM, eMMC, SD card slot, HDMI, USB micro-B port, Ethernet via USB3, USB3 host port, SATA, a GPIO expansion header, and an analog audio jack. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* | ARM: tegra: Add e2220-1170 boardStephen Warren2015-08-06-0/+67
| | | | | | | | | | | | | | | | | | E2220-1170 is a Tegra210 bringup board with onboard SoC, DRAM, eMMC, SD card slot, HDMI, USB micro-B port, and sockets for various expansion modules. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* | ARM: tegra: enable GPU DT node when appropriateAlexandre Courbot2015-08-06-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | T124/210 requires some specific configuration (VPR setup) to be performed by the bootloader before the GPU can be used. For this reason, the GPU node in the device tree is disabled by default. This patch enables the node if U-boot has performed VPR configuration. Boards enabled by this patch are T124's Jetson TK1 and Venice2 and T210's P2571. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Tom Warren <twarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* | ARM: tegra: move VPR configuration to a later stageAlexandre Courbot2015-08-06-18/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | U-boot is responsible for enabling the GPU DT node after all necessary configuration (VPR setup for T124) is performed. In order to be able to check whether this configuration has been performed right before booting the kernel, make it happen during board_init(). Also move VPR configuration into the more generic gpu.c file, which will also host other GPU-related functions, and let boards specify individually whether they need VPR setup or not. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Tom Warren <twarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* | ARM: tegra: restrict usable RAM size furtherStephen Warren2015-08-06-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Additionally, ARM64 devices typically run a secure monitor in EL3 and U-Boot in EL2, and set up some secure RAM carve-outs to contain the EL3 code and data. These carve-outs are located at the top of 32-bit address space. Restrict U-Boot's RAM usage to well below the location of those carve-outs. Ideally, we would the secure monitor would inform U-Boot of exactly which RAM it could use at run-time. However, I'm not sure how to do that at present (and even if such a mechanism does exist, it would likely not be generic across all forms of secure monitor). Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* | Tegra: PLL: use per-SoC pllinfo table instead of PLL_DIVM/N/P, etc.Tom Warren2015-08-05-174/+285
| | | | | | | | | | | | | | | | | | | | | | | | | | Added PLL variables (dividers mask/shift, lock enable/detect, etc.) to new pllinfo struct for each Soc/PLL. PLLA/C/D/E/M/P/U/X. Used pllinfo struct in all clock functions, validated on T210. Should be equivalent to prior code on T124/114/30/20. Thanks to Marcel Ziswiler for corrections to the T20/T30 values. Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* | Tegra: clocks: Add 38.4MHz OSC support for T210 useTom Warren2015-08-05-6/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added 38.4MHz/48MHz entries to pll_x_table for CPU PLL. Needs to be measured - should be close to 700MHz (1.4G/2). Note that some freqs aren't in the PLLU table in T210 TRM (13, 26MHz), so I used the 12MHz table entry for them. They shouldn't be selected since they're not viable T210 OSC freqs. Since there are now 2 new OSC defines, all tables (pll_x_table, PLLU) had to increase by two entries, but since 38.4/48MHz are not viable osc freqs on T20/30/114, etc, they're just set to 0. Signed-off-by: Tom Warren <twarren@nvidia.com>
* | T210: P2571: Turn CPU fan onTom Warren2015-08-05-0/+3
|/ | | | | | | | CPU board (E2530) has a fan - turn it on via GPIO to keep the SoC cool. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* Merge git://git.denx.de/u-boot-x86Tom Rini2015-08-05-136/+5552
|\
| * x86: qemu: Support operation as an EFI payloadSimon Glass2015-08-05-1/+6
| | | | | | | | | | | | | | | | | | Disable a few things which interfere with the EFI init. This allows QEMU to to boot into EFI, load a U-Boot payload then boot to the U-Boot prompt. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: baytrail: Support operation as an EFI payloadSimon Glass2015-08-05-1/+5
| | | | | | | | | | | | | | | | | | Disable a few things which interfere with the EFI init. This allows the Minnowboard MAX to boot into EFI, load a U-Boot payload then boot to the U-Boot prompt. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: Add helper code for running from EFISimon Glass2015-08-05-0/+165
| | | | | | | | | | | | | | | | | | | | When U-Boot is running from EFI some of the x86 init is replaced with EFI-specific init. For example, since DRAM has already been set up, we only need to find it, not init it. Add these functions so that boards can easily allow booting from EFI if required. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: Handle running as EFI payloadSimon Glass2015-08-05-10/+43
| | | | | | | | | | | | | | | | | | When U-Boot runs as an EFI payload it needs to avoid setting up the CPU again. Also U-Boot currently does not handle interrupts for many devices, so run with interrupts disabled. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: Add support for passing tables into U-BootSimon Glass2015-08-05-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | The EFI stub provides information to U-Boot in a table. This includes the memory map which is needed to decide where to relocate U-Boot. Collect this information in the early init code and store it in global_data. Fix up the BIST code at the same time since we don't have it when booting from EFI and can assume it is 0. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * efi: Add 64-bit payload supportSimon Glass2015-08-05-1/+65
| | | | | | | | | | | | | | | | | | | | | | | | Most EFI implementations use 64-bit. Add a way to build U-Boot as a 64-bit EFI payload. The payload unpacks a (32-bit) U-Boot and starts it. This can be enabled for x86 boards at present. Signed-off-by: Simon Glass <sjg@chromium.org> Improvements to how the payload is built: Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: Add a way to call 32-bit code from 64-bit modeSimon Glass2015-08-05-0/+79
| | | | | | | | | | | | | | | | | | The procedure to drop from 64-bit mode to 32-bit is a bit messy. Add a function to take care of it. It requires identity-mapped pages and that the calling code is running below 4GB. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: Add an enum for some commonly-used GDT bitsSimon Glass2015-08-05-0/+18
| | | | | | | | | | | | | | | | Rather than add these as open-coded values, create an enum with the commonly used flags. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: Support building the EFI stubSimon Glass2015-08-05-1/+25
| | | | | | | | | | | | | | | | Add support for building a 32/64-bit EFI stub for x86. This involves building the startup and relocation code for either i386 or x86_64. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * efi: Add support for loading U-Boot through an EFI stubSimon Glass2015-08-05-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is useful to be able to load U-Boot onto a board even if is it already running EFI. This can allow access to the U-Boot command interface, flexible booting options and easier development. The easiest way to do this is to build U-Boot as a binary blob and have an EFI stub copy it into RAM. Add support for this feature, targeting 32-bit initially. Also add a way to detect when U-Boot has been loaded via a stub. This goes in common.h since it needs to be widely available so that we avoid redoing initialisation that should be skipped. Signed-off-by: Simon Glass <sjg@chromium.org> Improvements to how the payload is built: Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: Add relocation and link script for a 64-bit EFI applicationSimon Glass2015-08-05-0/+149
| | | | | | | | | | | | | | | | | | | | Add a linker script and relocation code for building 64-bit EFI applications. This can be used for the EFI stub. Signed-off-by: Simon Glass <sjg@chromium.org> Improvements to how the payload is built: Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: Allow relocation code to build without text baseSimon Glass2015-08-05-6/+11
| | | | | | | | | | | | | | | | | | This code currently requires CONFIG_SYS_TEXT_BASE but this should be unnecessary. As a first step, remove the build-time limitation and report an error instead. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: dts: Add a device tree file for EFISimon Glass2015-08-05-0/+23
| | | | | | | | | | | | | | | | This contains just enough to bring up the serial UART. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: Add EFI board codeBen Stoltz2015-08-05-0/+1
| | | | | | | | | | | | | | | | | | | | Add support for the efi-x86 board, which supports running U-Boot as an EFI 32-bit application. Signed-off-by: Ben Stoltz <stoltz@google.com> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
generated by cgit v1.1 at 2024-11-16 02:27:18 +0000