summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeLines
...
| * dm: i2c: Move definitions to the top of the header fileSimon Glass2015-08-05-43/+43
| | | | | | | | | | | | | | | | Move the flags and struct definitions higher in the file so that we can reference them with functions declared in the driver model section. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de>
| * dm: i2c: Correct comment nits in dm_i2c_reg_read/write()Simon Glass2015-08-05-0/+2
| | | | | | | | | | | | | | Add documentation for the @dev parameter. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de>
| * dm: i2c: Add a message debug functionSimon Glass2015-08-05-0/+26
| | | | | | | | | | | | | | Add a way to dump the contents of an I2C message for debugging purposes. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de>
| * dm: core: Support finding a device by phandleSimon Glass2015-08-05-0/+59
| | | | | | | | | | | | | | | | | | It is common for one node to reference another via a phandle. Add support for obtaining an attached device by this method. As an example, a node may have a 'power-supply' property which references a regulator, allowing the driver to turn on its power. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: usb: fix USB Ethernet without CONFIG_DM_ETH regressionMarcel Ziswiler2015-08-05-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following commit enforces CONFIG_DM_ETH for USB Ethernet which breaks any board using CONFIG_USB_HOST_ETHER without CONFIG_DM_ETH which this patch fixes. commit 69559093f6173dcfcb041df0995063bdbd07d49b dm: usb: Avoid using USB ethernet with CONFIG_DM_USB and no DM_ETH Tested on Colibri T20/T30 as well as Apalis T30 with CONFIG_USB_HOST_ETHER and CONFIG_USB_ETHER_ASIX enabled and a LevelOne USB-0301 ASIX AX88772 dongle. Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Acked-by: Simon Glass <sjg@chromium.org>
* | ARM: tegra: Add p2371-0000 boardStephen Warren2015-08-06-0/+496
| | | | | | | | | | | | | | | | | | | | | | 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/+503
| | | | | | | | | | | | | | | | | | 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: p2571: remove another unused defineStephen Warren2015-08-06-3/+0
| | | | | | | | | | | | | | | | CONFIG_MAX77620_POWER isn't used anywhere. Don't define it in p2571.h. 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: enable GPU DT node when appropriateAlexandre Courbot2015-08-06-0/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: add comment re: autogeneration to pinmux headersStephen Warren2015-08-06-0/+32
| | | | | | | | | | | | | | | | | | | | Add a comment block to the top of each generated Tegra pinmux header file indicating that the file was auto-generated, should not be manually edited, and with a pointer to the tool and command used to generate it. 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: 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: P2571: Clean up config fileTom Warren2015-08-05-6/+1
| | | | | | | | | | | | | | Removed NS16550_COM1 #define, not used since there's no SPL for T210 Also changed the number of USB controllers to 1 as only USBD is used. Signed-off-by: Tom Warren <twarren@nvidia.com>
* | Tegra: spi: Move TEGRA114_SPI switch to defconfigsTom Warren2015-08-05-10/+5
| | | | | | | | | | | | | | | | | | | | | | All T114+ Tegra boards should be using the Kconfig TEGRA114_SPI switch. Remove it from include/config and put it into defconfig. Also removed unused TEGRA114_SPI_CTRLS from T114+ configs. All Tegra SoCs build OK with this change. 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-11/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+15
| | | | | | | | | | | | | | | | 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>
* | T210: P2571: Restore USB gadget mode (ums)Tom Warren2015-08-05-0/+1
| | | | | | | | | | | | | | | | | | | | The tegra-common-usb-gadget.h include was causing some build problems in ci_udc.c with a 64-bit gcc in an earlier version of the T210 patches, but it is working fine now, so restore it. Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* | T210: P2571: Enable SD-card power via PMIC LDO2Tom Warren2015-08-05-87/+24
|/ | | | | | | | This was done in the 32-bit AVP loader (SPL) but is board-specific so should be moved to the CPU portion. Signed-off-by: Tom Warren <twarren@nvidia.com> Acked-by: Stephen Warren <swarren@nvidia.com>
* configs: Remove CONFIG_SERIAL_MULTIStephen Warren2015-08-05-16/+0
| | | | | | | This config option isn't used anywhere at all. Remove all places that define/enable the option. Signed-off-by: Stephen Warren <swarren@nvidia.com>
* Merge git://git.denx.de/u-boot-x86Tom Rini2015-08-05-235/+8325
|\
| * x86: Document how to write PIRQ information in the device treeBin Meng2015-08-05-0/+41
| | | | | | | | | | | | | | | | Document the development flow on figuring out PIRQ information during the U-Boot porting. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * pci: Remove DEBUG from pci_compat.cBin Meng2015-08-05-1/+0
| | | | | | | | | | | | | | Remove DEBUG in drivers/pci/pci_compat.c. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * efi: Add a README to explain how things workSimon Glass2015-08-05-0/+237
| | | | | | | | | | | | | | | | Add some documentation on the EFI implementation in U-Boot. Signed-off-by: Ben Stoltz <stoltz@google.com> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: Gracefully disable the vesa driver when running from EFISimon Glass2015-08-05-0/+8
| | | | | | | | | | | | | | | | | | | | | | We cannot use this driver when running from EFI as we have no direct hardware access. In fact coreboot uses a different driver which uses tables provided by coreboot. So far it does not seem possible to use a normal video driver when booting from EFI. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: qemu: Support operation as an EFI payloadSimon Glass2015-08-05-3/+9
| | | | | | | | | | | | | | | | | | 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-3/+8
| | | | | | | | | | | | | | | | | | 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>
| * efi: Add a command to display the memory mapSimon Glass2015-08-05-0/+258
| | | | | | | | | | | | | | | | | | | | The EFI memory map is passed from the stub to U-Boot in a table. Add a command to display it in a vaguely readable fashion. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested on QEMU Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * efi: Add functions for decoding the EFI tablesSimon Glass2015-08-05-0/+48
| | | | | | | | | | | | | | | | The EFI stub can pass a table to U-Boot with information about the memory map Potentially other things will follow. Add a way to access this table. 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-6/+143
| | | | | | | | | | | | | | | | | | | | | | | | 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/+376
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Add definitions for the x86-efi board and plumb it inBen Stoltz2015-08-05-0/+50
| | | | | | | | | | | | | | | | Add configuration and Kconfig changes for this board. Signed-off-by: Ben Stoltz <stoltz@google.com> Signed-off-by: Simon Glass <sjg@chromium.org> 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/+66
| | | | | | | | | | | | | | | | | | | | 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>
| * x86: Add support for U-Boot as an EFI applicationBen Stoltz2015-08-05-0/+319
| | | | | | | | | | | | | | | | | | | | Add the required x86 glue code. This includes the initial start-up, relocation and jumping to efi_main(). We also need to avoid fiddling with interrupts. Signed-off-by: Ben Stoltz <stoltz@google.com> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: Add asm/elf.h for x86-specific ELF definitionsSimon Glass2015-08-05-0/+46
| | | | | | | | | | | | | | | | Bring in this file from Linux 4.1. It supports relocation features specific to x86. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: Support skipping relocation for EFISimon Glass2015-08-05-0/+6
| | | | | | | | | | | | | | | | When running as an EFI application we must skip relocation. Add support for this in the x86 relocation code. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * efi: Support building a u-boot-app.efi executableSimon Glass2015-08-05-0/+5
| | | | | | | | | | | | | | | | | | Add support for building U-Boot as an EFI application with a .efi suffix. This can be loaded by EFI provided that EFI has the same bit width (32- or 64-bit) as U-Boot. This unfortunate limitation is imposed by EFI. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: Set up toolchain flags for running as EFI applicationBen Stoltz2015-08-05-3/+27
| | | | | | | | | | | | | | | | | | | | Adjust the toolchain flags to build U-Boot as a relocatable shared library, as required by EFI. 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>
| * efi: Drop CONFIG_SYS_TEXT_BASE for EFIBen Stoltz2015-08-05-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | When U-Boot runs as an EFI application is does not have a definition of CONFIG_SYS_TEXT_BASE. U-Boot is a relocatable application and the relocation is done by EFI. U-Boot can be loaded at any address. Ensure that this CONFIG option is not set in this case. Signed-off-by: Ben Stoltz <stoltz@google.com> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * efi: Add a serial driverSimon Glass2015-08-05-0/+167
| | | | | | | | | | | | | | | | | | Add a serial driver which makes use of EFI's console in/out service. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested on Intel Crown Bay and QEMU Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * Add a way to skip relocationSimon Glass2015-08-05-0/+10
| | | | | | | | | | | | | | | | | | | | | | When running U-Boot as an EFI application we cannot relocate since we do not have relocation information. U-Boot has already been relocated to a suitable address. Add a global_data flag to control skipping relocation. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
generated by cgit v1.1 at 2024-10-09 19:27:32 +0000