- 08 8月, 2015 6 次提交
-
-
由 Marek Vasut 提交于
Define two missing reset manager registers, which are in the SoCFPGA CV datasheet. Signed-off-by: NMarek Vasut <marex@denx.de>
-
由 Marek Vasut 提交于
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: NMarek Vasut <marex@denx.de>
-
由 Marek Vasut 提交于
This file is absolutelly positively board specific, so move it into the correct place. Signed-off-by: NMarek Vasut <marex@denx.de>
-
由 Dinh Nguyen 提交于
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: NDinh Nguyen <dinguyen@opensource.altera.com>
-
由 Marek Vasut 提交于
Add alias for the SD/MMC controller, so it can be located by U-Boot OF support. Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
-
由 Marek Vasut 提交于
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: NMarek Vasut <marex@denx.de> Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
-
- 07 8月, 2015 5 次提交
-
-
由 Stephen Warren 提交于
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: NStephen Warren <swarren@nvidia.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
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: NStephen Warren <swarren@nvidia.com> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Alexandre Courbot 提交于
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: NAlexandre Courbot <acourbot@nvidia.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Tom Warren <twarren@nvidia.com> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Alexandre Courbot 提交于
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: NAlexandre Courbot <acourbot@nvidia.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Tom Warren <twarren@nvidia.com> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
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: NStephen Warren <swarren@nvidia.com> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
- 06 8月, 2015 17 次提交
-
-
由 Simon Glass 提交于
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: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
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: NSimon Glass <sjg@chromium.org> Reviewed-by: NLukasz Majewski <l.majewski@samsung.com>
-
由 Simon Glass 提交于
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: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
We always use device tree on exynos, so remove the unused code. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
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: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
The driver supports driver model. Add a node for snow, which needs it. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
The new driver supports driver model and configuration via device tree. Add a node for pit, which needs this driver. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
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: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
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: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Allow this function to be selected using the pinmux API. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
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: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
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: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
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: NSimon Glass <sjg@chromium.org> Acked-by: NPrzemyslaw Marczak <p.marczak@samsung.com>
-
由 Simon Glass 提交于
The kernel uses upper case for I2C unit addresses. Follow the same convention to reduce differences. Signed-off-by: NSimon Glass <sjg@chromium.org> Acked-by: NPrzemyslaw Marczak <p.marczak@samsung.com>
-
由 Tom Warren 提交于
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: NMarcel Ziswiler <marcel.ziswiler@toradex.com> Tested-by: NMarcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Tom Warren 提交于
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: NTom Warren <twarren@nvidia.com>
-
由 Tom Warren 提交于
CPU board (E2530) has a fan - turn it on via GPIO to keep the SoC cool. Acked-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
- 05 8月, 2015 12 次提交
-
-
由 Hans de Goede 提交于
USB_KEYBOARD is now defined in drivers/usb/Kconfig, drop our own duplicate definition. Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Paul Kocialkowski 提交于
USB-related options are usually prefixed with CONFIG_USB and platform-specific adaptation for the MUSB controller already have a CONFIG_USB_MUSB prefix, so this switches all MUSB-related options to a CONFIG_USB_MUSB prefix, for consistency. Signed-off-by: NPaul Kocialkowski <contact@paulk.fr>
-
由 Simon Glass 提交于
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: NSimon Glass <sjg@chromium.org> Reviewed-by: NBin Meng <bmeng.cn@gmail.com> Tested-by: NBin Meng <bmeng.cn@gmail.com>
-
由 Simon Glass 提交于
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: NSimon Glass <sjg@chromium.org> Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
-
由 Simon Glass 提交于
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: NSimon Glass <sjg@chromium.org> Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
-
由 Simon Glass 提交于
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: NSimon Glass <sjg@chromium.org> Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
-
由 Simon Glass 提交于
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: NSimon Glass <sjg@chromium.org> Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
-
由 Simon Glass 提交于
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: NSimon Glass <sjg@chromium.org> Improvements to how the payload is built: Signed-off-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NBin Meng <bmeng.cn@gmail.com> Tested-by: NBin Meng <bmeng.cn@gmail.com>
-
由 Simon Glass 提交于
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: NSimon Glass <sjg@chromium.org> Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
-
由 Simon Glass 提交于
Rather than add these as open-coded values, create an enum with the commonly used flags. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
-
由 Simon Glass 提交于
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: NSimon Glass <sjg@chromium.org> Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
-
由 Simon Glass 提交于
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: NSimon Glass <sjg@chromium.org> Improvements to how the payload is built: Signed-off-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NBin Meng <bmeng.cn@gmail.com> Tested-by: NBin Meng <bmeng.cn@gmail.com>
-