summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeLines
* imx: mx7: discard unused global variablePeng Fan2015-09-24-2/+0
| | | | | | | Discard unused global variable. Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Cc: Stefano Babic <sbabic@denx.de>
* imx: boards: Add maintainers infoPeng Fan2015-09-24-0/+5
| | | | | | | Add MAINTAINERS info for mx6slevk_spl, mx6ul_9x9_evk and mx6qpsabreauto. Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Cc: Stefano Babic <sbabic@denx.de>
* imx-common: consider mux_ctrl_ofs when setting mux_modePeng Fan2015-09-24-4/+3
| | | | | | | | | | | | | | | | | | | | Some i.MXes use __NA_ or 0 to avoid setting mux_mode, but the following patch only take i.MX6/7 into consideration. "c3c8a5748897b24f18618047804317167a531dd3 imx-common: fix iomux settings" Use is_soc_type(MXC_CPU_MX7) to avoid breaking other i.MXes when setting mux_mode. In this patch, switch to use "asm/imx-common/sys_proto.h" to avoid build break for "is_soc_type" for vf610 and mx25. Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Cc: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Acked-by: Stefano Babic <sbabic@denx.de> Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
* cgtqmx6eval: Add USB Mass Storage supportOtavio Salvador2015-09-20-0/+14
| | | | | | | | | | => ums 0 mmc 0 (Mounts the micro SD) => ums 0 mmc 1 (Mounts the eMMC) => ums 0 mmc 2 (Mounts the big SD) Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
* cgtqmx6eval: Add a maintainer entryOtavio Salvador2015-09-20-2/+2
| | | | | | Add me as the board maintainer and move the status to 'Maintained'. Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
* cgtqmx6eval: Fit into a single lineOtavio Salvador2015-09-20-2/+1
| | | | | | | The printf can be put in a single line of code, so make it simpler Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
* imx6, aristaintetos2: add me as maintainerHeiko Schocher2015-09-20-0/+1
| | | | | | Add me as Maintainer for the aristainetos2b board. Signed-off-by: Heiko Schocher <hs@denx.de>
* mtd: nand: mxs check maximum ecc that platfrom supportsPeng Fan2015-09-20-1/+8
| | | | | | | | | | | | Check maximum ecc strength for each platfrom to avoid the calculated ecc exceed the limitation. Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Signed-off-by: Han Xu <b45815@freescale.com> Tested-By: Tim Harvey <tharvey at gateworks.com> Reviewed-by: Marek Vasut <marex@denx.de> Acked-by: Scott Wood <scottwood@freescale.com> Cc: Stefano Babic <sbabic@denx.de>
* imx: mx7dsabresd: drop SYS_SOC from board KconfigPeng Fan2015-09-20-3/+0
| | | | | | | | We have defined this kconfig entry in arch/arm/cpu/armv7/mx7/Kconfig, no need to redefine it in board Kconfig. Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Cc: Stefano Babic <sbabic@denx.de>
* imx: mx7: drop select CPU_V7 for board targetPeng Fan2015-09-20-1/+0
| | | | | | | drop select CPU_V7 for board target, since ARCH_MX7 selects CPU_V7. Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Cc: Stefano Babic <sbabic@denx.de>
* mx6ul_14x14_evk: Remove get_board_rev()Fabio Estevam2015-09-20-5/+0
| | | | | | | | | | | get_board_rev() is not actually providing the board revision. It just returns the CPU revision instead. As the CPU revision is already printed on boot, there is no reason to have get_board_rev(), so let's remove it. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
* mx6ul_14x14_evk: Staticize when possibleFabio Estevam2015-09-20-2/+2
| | | | | | | | Make the internal symbols static when possible. This prevents sparse build warnings. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
* mx6ul_14x14_evk: Remove dead codeFabio Estevam2015-09-20-43/+0
| | | | | | iox74lv_set() is not used anywhere, so let's remove it. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
* mx7dsabresd: Remove unused config optionFabio Estevam2015-09-20-1/+0
| | | | | | CONFIG_FEC_DMA_MINALIGN is not used anywhere, so let's remove it. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
* mx7dsabresd: Remove get_board_rev()Fabio Estevam2015-09-20-5/+0
| | | | | | | | | | | get_board_rev() is not actually providing the board revision. It just returns the CPU revision instead. As the CPU revision is already printed on boot, there is no reason to have get_board_rev(), so let's remove it. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
* mx7dsabresd: Include USB headerFabio Estevam2015-09-20-0/+1
| | | | | | | | Include <usb/ehci-fsl.h> in order to fix the following sparse warning: board/freescale/mx7dsabresd/mx7dsabresd.c:538:5: warning: symbol 'board_ehci_hcd_init' was not declared. Should it be static? Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
* mx7dsabreasd: Remove dead codeFabio Estevam2015-09-20-38/+0
| | | | | | iox74lv_set() is not used anywhere, so let's remove it. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
* mx7dsabresd: Staticize when possibleFabio Estevam2015-09-20-4/+4
| | | | | | | | Make the internal symbols static when possible. This prevents sparse build warnings. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
* mx6sabre_common: Add Fastboot supportFabio Estevam2015-09-20-0/+6
| | | | | | | | | | | | | | | | | | Tested basic fastboot commands, such as: On the mx6qsabresd U-boot prompt: => fastboot 0 On the host PC: $ fastboot getvar bootloader-version -i 0x0525 bootloader-version: U-Boot 2015.10-rc2-23960-g2462cce-dirty finished. total time: 0.000s $ fastboot reboot -i 0x0525 --> board reboots fine. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
* imx: mx7dsabresd set wdog SRS bitPeng Fan2015-09-20-1/+9
| | | | | | | | | | | We use trigger pmic reset to reset the board, so set bit SRS to disable internal WDOG_RESET_B_DEB to make reset stable. Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Adrian Alonso <aalonso@freescale.com> Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
* imx: wdog: correct wcr register settingsPeng Fan2015-09-20-1/+2
| | | | | | | | | | | | | We should not simple use "writew(WCR_WDE, &wdog->wcr)" to set wcr, since this will override bits set before reset_cpu. Use clrsetbits_le16 instead of writew to fix this issue. Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Sebastian Siewior <bigeasy@linutronix.de> Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
* imx-common: fix iomux settingsPeng Fan2015-09-20-2/+1
| | | | | | | | | | | | When setting iomux for a pin mux, there is no need to check mux_ctrl_ofs. Also If still checking mux_ctrl_ofs, we have no chance to set iomux for i.MX7D IOMUXC_LPSR_SW_MUX_CTL_PAD_GPIO1_IO00, because the mux_ctrl_ofs for this register is 0. Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
* Merge git://git.denx.de/u-boot-x86Tom Rini2015-09-17-70/+400
|\
| * x86: quark: Configure MTRR to enable cacheBin Meng2015-09-16-0/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Quark SoC does not support MSR MTRRs. Fixed and variable range MTRRs are accessed indirectly via the message port and not the traditional MSR mechanism. Only UC, WT and WB cache types are supported. We configure all the fixed range MTRRs with common values (VGA RAM as UC, others as WB) and 3 variable range MTRRs for ROM/eSRAM/RAM as WB, which significantly improves the boot time performance. With this commit, it takes only 2 seconds for U-Boot to boot to shell on Intel Galileo board. Previously it took about 6 seconds. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
| * x86: doc: Add DMI to the TODO listBin Meng2015-09-16-0/+2
| | | | | | | | | | | | | | | | Desktop Management Interface (DMI) is not supported by U-Boot now. Add it to the TODO list. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * x86: doc: Document some porting hints about Intel QuarkBin Meng2015-09-16-0/+24
| | | | | | | | | | | | | | | | Document porting considerations for Intel Quark based board, including MRC parameters and PCIe initialization. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * x86: galileo: Add PCIe root port IRQ routingBin Meng2015-09-16-0/+12
| | | | | | | | | | | | | | | | Now we have enabled PCIe root port on Quark SoC, add its PIRQ routing information in the device tree as well. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * x86: quark: Initialize thermal sensor properlyBin Meng2015-09-16-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Thermal sensor on Quark SoC needs to be properly initialized per Quark firmware writer guide, otherwise when booting Linux kernel, it triggers system shutdown because of wrong temperature in the thermal sensor is detected by the kernel driver (see below): [ 5.119819] thermal_sys: Critical temperature reached(206 C),shutting down [ 5.128997] Failed to start orderly shutdown: forcing the issue [ 5.135495] Emergency Sync complete Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * x86: quark: Lock HMBOUND register before jumping to kernelBin Meng2015-09-16-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When Linux kernel boots, it hangs at: [ 0.829408] Intel Quark side-band driver registered This happens when Quark kernel Isolated Memory Region (IMR) driver tries to lock an IMR register to protect kernel's text and rodata sections. However in order to have IMR function correctly, HMBOUND register must be locked otherwise the system just hangs. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * x86: quark: Convert to use clrbits, setbits, clrsetbits macrosBin Meng2015-09-16-51/+21
| | | | | | | | | | | | | | Change existing codes to use clrbits, setbits, clrsetbits macros. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * x86: quark: Add clrbits, setbits, clrsetbits macros for message port accessBin Meng2015-09-16-0/+31
| | | | | | | | | | | | | | | | | | On Intel Quark, lots of registers on the message port need be programmed. Add handy clrbits, setbits, clrsetbits macros for message port access. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * x86: galileo: Enable random mac address for QuarkBin Meng2015-09-16-0/+1
| | | | | | | | | | | | | | | | | | | | Not like other Intel Ethernet controllers (e.g.: E1000), Intel Quark SoC integrated designware Ethernet controller does not have a chipset defined way to store/restore mac address. Enable random mac address so that we can use Ethernet even without 'ethaddr'. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * x86: quark: Add PCIe/USB static register programming after memory initBin Meng2015-09-16-0/+87
| | | | | | | | | | | | | | | | | | This adds static register programming for PCIe and USB after memory init as required by Quark firmware writer guide. Although not doing this did not cause any malfunction, just do it for safety. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * x86: Convert to use driver model eth on quark/galileoBin Meng2015-09-16-20/+1
| | | | | | | | | | | | | | | | Convert to use DM version of Designware ethernet driver on Intel quark/galileo. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * net: designware: Add support to PCI designware devicesBin Meng2015-09-16-0/+42
| | | | | | | | | | | | | | | | The Designware ethernet controller is also seen on PCI bus, e.g. on Intel Quark SoC. Add this support in the DM version driver. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * dm: pci: Add an inline API to test if a device is on a PCI busBin Meng2015-09-16-2/+13
| | | | | | | | | | | | | | | | Introduce device_is_on_pci_bus() which can be utilized by driver to test if a device is on a PCI bus. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* | Merge git://git.denx.de/u-boot-dmTom Rini2015-09-17-0/+1
|\ \
| * | dts: do not cut down pinctrl-0 and pinctrl-names for SPL full-pinctrlMasahiro Yamada2015-09-16-0/+1
| |/ | | | | | | | | | | | | | | These properties are necessary to use full-featured pinctrl drivers in SPL. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
* | ARM: tegra114: Clear IDDQ when enabling PLLCThierry Reding2015-09-16-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | Enabling a PLL while IDDQ is high. The Linux kernel checks for this condition and warns about it verbosely, so while this seems to work fine, fix it up according to the programming guidelines provided in the Tegra K1 TRM (v02p), Section 5.3.8.1 ("PLLC and PLLC4 Startup Sequence"). The Tegra114 TRM doesn't contain this information, but the programming of PLLC is the same on Tegra114 and Tegra124. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* | ARM: tegra124: Clear IDDQ when enabling PLLCThierry Reding2015-09-16-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | Enabling a PLL while IDDQ is high. The Linux kernel checks for this condition and warns about it verbosely, so while this seems to work fine, fix it up according to the programming guidelines provided in the Tegra K1 TRM (v02p), Section 5.3.8.1 ("PLLC and PLLC4 Startup Sequence"). Reported-by: Nicolas Chauvet <kwizart@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* | ARM: tegra: Add Tegra20 SPI device nodesMirza Krak2015-09-16-0/+57
| | | | | | | | | | | | | | Add the device tree node for the SPI controllers found on Tegra20 SOCs. Signed-off-by: Mirza Krak <mirza.krak@hostmobility.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* | p2571: Remove hard-coded counter frequencyThierry Reding2015-09-16-2/+0
| | | | | | | | | | | | | | | | | | | | | | The counter frequency is derived from clk_m on Tegra, but that clock can be configured by the primary bootloader to run at the same frequency as the oscillator (38.4 MHz on Tegra210) or a divided down frequency (most typically 19.2 MHz). Remove the hard-coded frequency and allow the timer setup code to query the correct value at runtime. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* | p2371: Remove hard-coded counter frequencyThierry Reding2015-09-16-3/+0
| | | | | | | | | | | | | | | | | | | | | | The counter frequency is derived from clk_m on Tegra, but that clock can be configured by the primary bootloader to run at the same frequency as the oscillator (38.4 MHz on Tegra210) or a divided down frequency (most typically 19.2 MHz). Remove the hard-coded frequency and allow the timer setup code to query the correct value at runtime. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* | e2220-1170: Remove hard-coded counter frequencyThierry Reding2015-09-16-3/+0
| | | | | | | | | | | | | | | | | | | | | | The counter frequency is derived from clk_m on Tegra, but that clock can be configured by the primary bootloader to run at the same frequency as the oscillator (38.4 MHz on Tegra210) or a divided down frequency (most typically 19.2 MHz). Remove the hard-coded frequency and allow the timer setup code to query the correct value at runtime. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* | ARM: tegra: clk_m is the architected timer source clockThierry Reding2015-09-16-10/+8
| | | | | | | | | | | | | | | | | | | | | | While clk_m and the oscillator run at the same frequencies on Tegra114 and Tegra124, clk_m is the proper source for the architected timer. On more recent Tegra generations, Tegra210 and later, both the oscillator and clk_m can run at different frequencies. clk_m will be divided down from the oscillator. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* | ARM: tegra: Implement clk_mThierry Reding2015-09-16-2/+31
| | | | | | | | | | | | | | | | | | | | On currently supported SoCs, clk_m always runs at the same frequency as the oscillator input. However newer SoC generations such as Tegra210 no longer have that restriction. Prepare for that by separating clk_m from the oscillator clock and allow SoC code to override the clk_m rate. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* | armv8: Make COUNTER_FREQUENCY optionalThierry Reding2015-09-16-0/+2
| | | | | | | | | | | | | | | | | | | | Some platforms have the means to determine the counter frequency at runtime, so give them an opportunity to do so. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* | ARM: tegra: replace V_PROMPT define with kconfigStephen Warren2015-09-16-4/+4
| | | | | | | | | | | | | | | | | | Commit 181bd9dc61d2 "kconfig: add config option for shell prompt" replaced define V_PROMPT with Kconfig option SYS_PROMPT. This crossed with patches adding Tegra T210 boards. Migrate the boards to the new scheme. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* | ARM: tegra: fix PLLP frequency calc on T210Stephen Warren2015-09-16-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AFAIK, for all PLLs on all Tegra SoCs, the primary PLL output frequency is (input * m) / (n * p). However, PLLP's primary output (pllP_out0) on T210 is the VCO output, and divp is not applied. pllP_out2 does have divp applied. All other pllP_outN are divided down from pllP_out0. We only support pllP_out0 in U-Boot at the time of writing. Fix clock_get_rate() to handle this special case. This corrects the returned rate for PLLP to be 408MHz rather than 204MHz. In turn, this causes high enough dividers to be calculated for the various peripheral clocks that feed off of PLLP. Without this, some peripherals failed to operate correctly. For instance, one of my SD cards worked perfectly but an older (presumably slower) card could not be read. Note that prior to commit 722e000ccd72 "Tegra: PLL: use per-SoC pllinfo table instead of PLL_DIVM/N/P, etc.", the calculated PLL frequency was 816MHz since the wrong values were being extracted from the PLLP divider register. This caused overly large peripheral dividers to be calculated, which while wrong, didn't cause any correctness issues; things simply ran slower than they could. Reported-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
* | ARM: tegra: fix COUNTER_FREQUENCY for T210Stephen Warren2015-09-16-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While T210 boards all have 38.4MHz crystals, per the TRM, the only supported configuration is to divide the crystal frequency by 2 to generate clk_m, which is what feeds the ARM generic timers amongst other things. Fix the value of COUNTER_FREQUENCY to reflect this divide-by-2. When I queried the 19.2 value in Tom's original T210 patches, I wasn't aware of this extra divide-by-2, and didn't notice any effect from the incorrect value, since its only used if U-Boot is booted in EL3, whereas I'm booting it in EL2. Reported-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
generated by cgit v1.1 at 2024-11-11 22:34:31 +0000