summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeLines
* mx6: add example DTB for mx6qsabreautoStefano Babic2014-04-02-0/+17
| | | | | Signed-off-by: Stefano Babic <sbabic@denx.de> CC: Fabio Estevam <fabio.estevam@freescale.com>
* imx: add rules for U-Boot DTB supportStefano Babic2014-04-02-3/+15
| | | | Signed-off-by: Stefano Babic <sbabic@denx.de>
* mxs: fix warning in SPL with console supportStefano Babic2014-04-02-0/+2
| | | | Signed-off-by: Stefano Babic <sbabic@denx.de>
* arm: mxs: Add serial console support into SPLMarek Vasut2014-04-01-1/+14
| | | | | | | | | | | | | | | Add support for serial console into the i.MX23/i.MX28 SPL. A full, uncrippled serial console support comes very helpful when debugging various spectacular hardware bringup issues early in the process. Because we do not use SPL framework, but have our own minimalistic SPL, which is compatible with the i.MX23/i.MX28 BootROM, we do not use preloader_console_init(), but instead use a similar function to start the console. Nonetheless, to avoid blowing up the size of the SPL binary, this support is enabled only if CONFIG_SPL_SERIAL_SUPPORT is defined, which is disabled by default. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de>
* arm: mxs: Properly set GD pointer in SPLMarek Vasut2014-04-01-0/+5
| | | | | | | | Set the GD pointer in the SPL to a defined symbol so various functions from U-Boot can be used without adverse side effects. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de>
* arm: mx5: Avoid hardcoding memory sizes on M53EVKMarek Vasut2014-03-31-12/+27
| | | | | | | | | | | | | | | | | | | The DRAM size can be easily detected at runtime on i.MX53. Implement such detection on M53EVK and adjust the rest of the macros accordingly to use the detected values. An important thing to note here is that we had to override the function for trimming the effective DRAM address, get_effective_memsize(). That is because the function uses CONFIG_MAX_MEM_MAPPED as the upper bound of the available DRAM and we don't have gd->bd->bi_dram[0].size set up at the time the function is called, thus we cannot put this into the macro CONFIG_MAX_MEM_MAPPED . Instead, we use custom override where we use the size of the first DRAM block which we just detected. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Wolfgang Denk <wd@denx.de>
* arm: mx5: Fix memory slowness on M53EVKMarek Vasut2014-03-31-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix memory access slowness on i.MX53 M53EVK board. Let us inspect the issue: First of all, the i.MX53 CPU has two memory banks mapped at 0x7000_0000 and 0xb000_0000 and each of those can hold up to 1GiB of DRAM memory. Notice that the memory area is not continuous. On M53EVK, each of the banks contain 512MiB of DRAM, which makes a total of 1GiB of memory available to the system. The problem is how the relocation of U-Boot is treated on i.MX53 . The U-Boot is placed at the ((start of first DRAM partition) + (gd->ram_size)) . This in turn poses a problem, since in our case, the gd->ram_size is 1GiB, the first DRAM bank starts at 0x7000_0000 and contains 512MiB of memory. Thus, with this algorithm, U-Boot is placed at offset: 0x7000_0000 + 1GiB - sizeof(u-boot and some small margin) This is past the DRAM available in the first bank on M53EVK, but is still within the address range of the first DRAM bank. Because of the memory wrap-around, the data can still be read and written to this area, but the access is much slower. There were two ideas how to solve this problem, first was to map both of the available DRAM chunks next to one another by using MMU, second was to define CONFIG_VERY_BIG_RAM and CONFIG_MAX_MEM_MAPPED to size of the memory in the first DRAM bank. We choose the later because it turns out the former is not applicable afterall. The former cannot be used in case Linux kernel was loaded into the second DRAM bank area, which would be remapped and one would try booting the kernel, since at some point before the kernel is started, the MMU would be turned off, which would destroy the mapping and hang the system. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Wolfgang Denk <wd@denx.de>
* arm: mx5: Avoid hardcoding memory sizes on MX53QSBMarek Vasut2014-03-31-14/+29
| | | | | | | | | | | | | | | | | | | The DRAM size can be easily detected at runtime on i.MX53. Implement such detection on MX53QSB and adjust the rest of the macros accordingly to use the detected values. An important thing to note here is that we had to override the function for trimming the effective DRAM address, get_effective_memsize(). That is because the function uses CONFIG_MAX_MEM_MAPPED as the upper bound of the available DRAM and we don't have gd->bd->bi_dram[0].size set up at the time the function is called, thus we cannot put this into the macro CONFIG_MAX_MEM_MAPPED . Instead, we use custom override where we use the size of the first DRAM block which we just detected. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Wolfgang Denk <wd@denx.de>
* arm: mx5: Fix memory slowness on MX53QSBMarek Vasut2014-03-31-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix memory access slowness on i.MX53 MX53QSB board. Let us inspect the issue: First of all, the i.MX53 CPU has two memory banks mapped at 0x7000_0000 and 0xb000_0000 and each of those can hold up to 1GiB of DRAM memory. Notice that the memory area is not continuous. On MX53QSB, each of the banks contain 512MiB of DRAM, which makes a total of 1GiB of memory available to the system. The problem is how the relocation of U-Boot is treated on i.MX53 . The U-Boot is placed at the ((start of first DRAM partition) + (gd->ram_size)) . This in turn poses a problem, since in our case, the gd->ram_size is 1GiB, the first DRAM bank starts at 0x7000_0000 and contains 512MiB of memory. Thus, with this algorithm, U-Boot is placed at offset: 0x7000_0000 + 1GiB - sizeof(u-boot and some small margin) This is past the DRAM available in the first bank on MX53QSB, but is still within the address range of the first DRAM bank. Because of the memory wrap-around, the data can still be read and written to this area, but the access is much slower. There were two ideas how to solve this problem, first was to map both of the available DRAM chunks next to one another by using MMU, second was to define CONFIG_VERY_BIG_RAM and CONFIG_MAX_MEM_MAPPED to size of the memory in the first DRAM bank. We choose the later because it turns out the former is not applicable afterall. The former cannot be used in case Linux kernel was loaded into the second DRAM bank area, which would be remapped and one would try booting the kernel, since at some point before the kernel is started, the MMU would be turned off, which would destroy the mapping and hang the system. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Wolfgang Denk <wd@denx.de>
* ARM: mx6: Add PCIe on SabreSDPMarek Vasut2014-03-31-0/+21
| | | | | | | | | | Add support for PCIe on MX6 SabreSDP board and enable the support in the config file. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Liu Ying <Ying.Liu@freescale.com>
* pci: mx6: Implement power callbackMarek Vasut2014-03-31-1/+12
| | | | | | | | | | | | Implement a callback to toggle the slot power supply. The callback can be overriden in case some more complex power supply for the slot was implemented in hardware, yet for the usual case, one can define a GPIO which toggles the power to the slot. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Liu Ying <Ying.Liu@freescale.com>
* ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6xEric Nelson2014-03-31-1/+0
| | | | | | | | | | | | Use of PCIe on SABRE Lite and Nitrogen6x boards is atypical and requires the use of custom daughter boards. Use in U-Boot is even rarer, so this patch removes it from the standard configuration. Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com> Acked-by: Marek Vasut <marex@denx.de>
* woodburn_sd: Remove CONFIG_BOOT_INTERNALFabio Estevam2014-03-31-2/+0
| | | | | | | CONFIG_BOOT_INTERNAL is not used anywhere, so let's remove it. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Acked-by: Stefano Babic <sbabic@denx.de>
* ARM: mxs: Add OCOTP driverMarek Vasut2014-03-31-0/+317
| | | | | | | | | | | | Add yet another OCOTP driver for this i.MX family. This time, it's a driver for the OCOTP variant found in the i.MX23 and i.MX28. This version of OCOTP is too different from the i.MX6 one that I could not use the mxc_ocotp.c driver without making it into a big pile of #ifdef . This driver implements the regular fuse command interface, but due to the IP blocks' limitation, we support only READ and PROG functions. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de>
* arm: mxs: Add support for generating signed BootStreamMarek Vasut2014-03-31-0/+89
| | | | | | | | | | | | | | | | | | | | | | | This patch adds the groundwork for generating signed BootStream, which can be used by the HAB library in i.MX28. We are adding a new target, u-boot-signed.sb , since the process for generating regular non-signed BootStream is much easier. Moreover, the signed bootstream depends on external _proprietary_ _binary-only_ tool from Freescale called 'cst', which is available only under NDA. To make things even uglier, the CST or HAB mandates a kind-of circular dependency. The problem is, unlike the regular IVT, which is generated by mxsimage, the IVT for signed boot must be generated by hand here due to special demands of the CST. The U-Boot binary (or SPL binary) and IVT are then signed by the CST as a one block. But here is the problem. The size of the entire image (U-Boot, IVT, CST blocks) must be appended at the end of IVT. But the size of the entire image is not known until the CST has finished signing the U-Boot and IVT. We solve this by expecting the CST block to be always 3904B (which it is in case two files, U-Boot and the hand-made IVT, are signed in the CST block). Signed-off-by: Marek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de>
* arm: mxs: Adjust the load address of U-Boot and SPL for HABMarek Vasut2014-03-31-10/+33
| | | | | | | | | | | | | | | | | | | | | | | | When using HAB, there are additional special requirements on the placement of U-Boot and the U-Boot SPL in memory. To fullfill these, this patch moves the U-Boot binary a little further from the begining of the DRAM, so the HAB CST and IVT can be placed in front of the U-Boot binary. This is necessary, since both the U-Boot and the IVT must be contained in single CST signature. To make things worse, the IVT must be concatenated with one more entry at it's end, that is the length of the entire CST signature, IVT and U-Boot binary in memory. By placing the blocks in this order -- CST, IVT, U-Boot, we can easily align them all and then produce the length field as needed. As for the SPL, on i.MX23/i.MX28, the SPL size is limited to 32 KiB, thus we place the IVT at 0x8000 offset, CST right past IVT and claim the size is correct. The HAB library accepts this setup. Finally, to make sure the vectoring in SPL still works even after moving the SPL from 0x0 to 0x1000, we add a small function which copies the vectoring code and tables to 0x0. This is fine, since the vectoring code is position independent. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de>
* mx25pdk: Align the environment with other FSL boardsFabio Estevam2014-03-12-5/+98
| | | | | | | | | | | Allow the boot of a device tree mainline kernel by aligning the environment variables with other FSL boards. Tested NFS boot of a dt 3.14-rc5 kernel. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Acked-by: Otavio Salvador <otavio@ossystems.com.br> Acked-by: Stefano Babic <sbabic@denx.de>
* ventana: Add Gateworks Ventana family supportTim Harvey2014-03-12-0/+2143
| | | | | | | | | Gateworks Ventana is a product family based on the i.MX6. This patch adds support for all boards in the Ventana family. Where possible, data from the boards EEPROM is used to determine various details about the board at runtime. Signed-off-by: Tim Harvey <tharvey@gateworks.com>
* Merge branch 'master' of git://git.denx.de/u-boot-armStefano Babic2014-03-05-82870/+36589
|\
| * arm: am335x: DXR2: Reset SMSC LAN9303 switch via GPIO upon bootupStefan Roese2014-03-04-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | Since the switch may be re-configured for VLAN usage in Linux (or any other OS), lets reset the switch to its default register values upon power-up. Otherwise network might not be available in U-Boot. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Heiko Schocher <hs@denx.de> Cc: Roger Meier <r.meier@siemens.com> Cc: Lukas Stockmann <lukas.stockmann@siemens.com> Cc: Tom Rini <trini@ti.com>
| * ARM: AM43xx: Change DDR3 Reset ValueDave Gerlach2014-03-04-1/+1
| | | | | | | | | | | | | | | | | | The bit DDR3_RST_DEF_VAL inside CTRL_DDR_IO represents the default value of the ddr reset value for DDR3 before the EMIF takes over. We must have this bit set high so that on exit from DeepSleep0 within the kernel the reset line has the proper value. Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
| * ARM: AM43xx: Write sdram_config to secure_emif_sdram_configDave Gerlach2014-03-04-0/+1
| | | | | | | | | | | | | | | | | | The register secure_emif_sdram_config in control module is copied to the EMIF sdram_config register when it is coming out of DeepSleep0 in order to ensure that the EMIF comes up for the correct type of DDR. Without this, resume can hang from within the kernel. Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
| * ARM: AM43xx: EMIF: configure self-refresh entry delayDave Gerlach2014-03-04-2/+2
| | | | | | | | | | | | | | | | | | | | Per a suggestion from the hardware team, program the emif_pwr_mgmt_ctrl and emif_pwr_mgmt_ctrl_shdw registers within the EMIF to hold the desired delay in cycles that the EMIF waits without an access to enter self-refresh, in this case 8192 cycles. With this, code desiring to enter self refresh only has to toggle one bit to enable it. Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
| * ARM: AM43xx: Add Ethernet boot support to SPLMugunthan V N2014-03-04-4/+8
| | | | | | | | | | | | | | Add Ethernet Boot support to SPL Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
| * ARM: AM4372: Update EMIF registers for DDR3Lokesh Vutla2014-03-04-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Updating EMIF_PHY_CTRL and adding EMIF_READ_WRITE_EXECUTION_THRESHOLD registers. In EMIF_PHY_CTRL: Updating [4:0]READ_LATENCY to 8, because at higher frequencies like 400MHz the read latency expected will be CL+3 as per tests from HW folks. Clearing [19]PHY_DIS_CALIB_RST bit as this is used onl for debug purpose. With out this resume is not working(Still waiting for PHY team to come back for better explanation). Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
| * ARM: DRA7xx: add support for reading cpsw 2nd mac from efuseMugunthan V N2014-03-04-0/+15
| | | | | | | | | | | | | | | | | | Adding support for reading cpsw 2nd mac address from efuse and pass it to kernel via dtb which will be used in dual emac mode of cpsw. Also correct the bit masking of mac id read from the efuse. Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
| * ARM: AM335x: add support for reading cpsw 2nd mac address from efuseMugunthan V N2014-03-04-0/+16
| | | | | | | | | | | | | | | | | | Adding support for reading cpsw 2nd mac address from efuse and pass it to kernel via dtb which will be used in dual emac mode of cpsw. Also adding mii command support to am335x common config. Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
| * ARM: AM43xx: Add CPSW support to AM43xx EPOS and GP EVMMugunthan V N2014-03-04-2/+162
| | | | | | | | | | | | | | | | Adding support for CPSW to AM43xx EPOS nad GP EVM which is connected to RMII and RGMII phy respectively and enable cpsw in config. Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
| * ARM: AM43xx: clocks: Enable CPGMAC clock controlMugunthan V N2014-03-04-0/+1
| | | | | | | | | | | | Enable CPGMAC clock control for AM43xx to use ethernet in U-Boot Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
| * drivers: net: cpsw: add support to have phy address from cpsw platform dataMugunthan V N2014-03-04-33/+22
| | | | | | | | | | | | | | | | | | | | | | | | Some platforms like AM437x have different EVMs with different phy addresses, so this patch adds support for passing phy address via cpsw plaform data. Also renamed phy_id to phy_addr so better understanding of the code. Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> [trini: Update BuR am335x_igep0033 pcm051_rev3 pcm051_rev1 cm_t335 pengwyn boards] Signed-off-by: Tom Rini <trini@ti.com>
| * Merge branch 'master' of git://git.denx.de/u-boot-armTom Rini2014-02-26-608/+5960
| |\ | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: arch/arm/cpu/armv7/config.mk board/ti/am43xx/mux.c include/configs/am43xx_evm.h Signed-off-by: Tom Rini <trini@ti.com>
| | * arm: Switch to -mno-unaligned-access when supported by the compilerTom Rini2014-02-26-138/+248
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we tell the compiler to optimize for ARMv7 (and ARMv6 for that matter) it assumes a default of SCTRL.A being cleared and unaligned accesses being allowed and fast at the hardware level. We set this bit and must pass along -mno-unaligned-access so that the compiler will still breakdown accesses and not trigger a data abort. To better help understand the requirements of the project with respect to unaligned memory access, the Documentation/unaligned-memory-access.txt file has been added as doc/README.unaligned-memory-access.txt and is taken from the v3.14-rc1 tag of the kernel. Cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Cc: Mans Rullgard <mans@mansr.com> Signed-off-by: Tom Rini <trini@ti.com>
| | * checkpatch.pl: Add warning for new __packed additionsTom Rini2014-02-26-0/+5
| | | | | | | | | | | | | | | | | | | | | While there are valid reasons to use __packed, often the answer is that you should be doing something else here instead. Signed-off-by: Tom Rini <trini@ti.com>
| | * arm: remove unneeded symbol offsets and _TEXT_BASEAlbert ARIBAUD2014-02-26-369/+24
| | | | | | | | | | | | | | | | | | | | | | | | Remove the last uses of symbol offsets in ARM U-Boot. Remove some needless uses of _TEXT_BASE. Remove all _TEXT_BASE definitions. Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
| | * arm: make _end compiler-generatedAlbert ARIBAUD2014-02-26-29/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | This prevents references to _end from generating absolute relocation records. This change is binary invariant for ARM targets. Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
| | * cm_t335: fix linker file to produce full ELFAlbert ARIBAUD2014-02-26-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Newly added cm_t335 was missed in commit 47ed5dd0 which made ARM targets produce full ELF files. Fix its linker script. This change is binary-invariant when only .dynsym, .dynstr, .dynamic, .plt, .interp and .gun sections are declared. Sections .hash, .got.plt, .dynbss and .ARM.exidx are also declared so that their (unused) content is moved out of the u-boot binary. Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
| | * Merge branch 'u-boot-ti/master' into 'u-boot-arm/master'Albert ARIBAUD2014-02-24-36/+2323
| | |\
| | | * ti814x: Fix illegal use of FP ops in clock_ti814x.cMåns Rullgård2014-02-21-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The function pll_sigma_delta_val uses "float" data which is not correct. The exact "why" of this mangling is lost to history, but this changes us to equivalent non-FP math to get the same results. Reported-by: Wolfgang Denk <wd@denx.de> Acked-by: Matt Porter <mporter@linaro.org>
| | | * omap4_common: config: remove I2C for SPL modeNishanth Menon2014-02-21-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 6789e84ecaa8f45d053084e08c381284a04abff7 (i2c, omap24xx: convert driver to new mutlibus/mutliadapter framework) intended to make I2C driver compatible with latest changes. It unfortunately has had a impact on size on SPL as well. For example on SDP4430, 32032 bytes before/MLO 35416 bytes after/MLO With this mentioned commit, MLO stops booting on SDP4430 as only 32K is accessible for non-secure (bootloader) s/w on GP devices and the size increase to 56K fails boot. On the latest u-boot commit e7be18225fbea76d1f0034b224f0d1e60f07cfcf, MLO is now at size 35592 bytes, However, I2C is not necessary for SPL to function as we use SR_I2C for controlling the PMIC. Disabling I2C reduces MLO to 32224 bytes which allows OMAP4 GP platform to boot up. Since this is common for all OMAP4 platforms, remove the need for I2C for SPL builds in the common config. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Sricharan R <r.sricharan@ti.com>
| | | * dra7xx_evm: Enable GPT commandsTom Rini2014-02-21-0/+11
| | | | | | | | | | | | | | | | Signed-off-by: Tom Rini <trini@ti.com>
| | | * am43xx_evm: Enable GPT commandsTom Rini2014-02-21-0/+9
| | | | | | | | | | | | | | | | Signed-off-by: Tom Rini <trini@ti.com>
| | | * am335x_evm: Enable GPT commandsTom Rini2014-02-21-0/+12
| | | | | | | | | | | | | | | | Signed-off-by: Tom Rini <trini@ti.com>
| | | * arm: omap: cm_t35: Remove CONFIG_SYS_BOOTMAPSZ to fix FDT Linux bootingStefan Roese2014-02-21-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With CONFIG_SYS_BOOTMAPSZ defined, recent Linux kernel booting results in this error: Booting using the fdt blob at 0x81f00000 Loading Kernel Image ... OK ERROR: Failed to allocate 0x1189d bytes below 0x80004000. device tree - allocation error FDT creation failed! hanging...### ERROR ### Please RESET the board ### Removing this define solves this issue. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Nikita Kiryanov <nikita@compulab.co.il> Cc: Igor Grinberg <grinberg@compulab.co.il> Cc: Tom Rini <trini@ti.com>
| | | * DRA7: fix ABB efuse offset for OPP_NOMNishanth Menon2014-02-21-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 194dd74ad919e57026f385aaab7f89acf7ea79ef (DRA7: add ABB setup for MPU voltage domain) Made an offset typo error by using 0x4A003B24 as the efuse offset for OPP_NOM. As per TI documentation, 0x4A003B24 is for OPP_OD, and 0x4A003B20 is for OPP_NOM. Fix the same. Reported-by: Praveen Rao <prao@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com>
| | | * ARM: OMAP4: fix DDR timings for OMAP4430 ES2.0Janne Grunau2014-02-21-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | DDR timings were broken since 47abc3df701d8bc26f311350aa523fc1d0f8ad4e for PandaBoard EA1. Signed-off-by: Janne Grunau <j@jannau.net>
| | | * OMAP3: fix default environment for mcx boardStefano Babic2014-02-21-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | Patch allows to load a script at the startup from MMC. Signed-off-by: Stefano Babic <sbabic@denx.de>
| | | * omap3: fix pinmux for mcx boardStefano Babic2014-02-21-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | New hardware version cannot recognize the SD-Card because the SYS_NRESWARM, set as GPIO, does not guarantee the required reset time. Change the pin function back to enable the SYS_NRESWARM signal driven by the SOC. Signed-off-by: Stefano Babic <sbabic@denx.de>
| | | * OMAP3: add missing gpio clock init and fix NAND SPL for mcx boardStefano Babic2014-02-21-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch contains the same fixes as commit 4b9b2c300a23ca4a85811918dc92e822a9571a87 (missing CONFIG_OMAP3_GPIO_2) and commit f9095aac793aa8917ab9b915c5d449e6dc8d3d30 (missing CONFIG_SPL_NAND_SOFTECC). Same issues are relevant for the mcx board, too. Signed-off-by: Stefano Babic <sbabic@denx.de>
| | | * arm: omap3: Fix tao3530/omap3_ha SPL boot hangup (GPIO clocks not enabled)Stefan Roese2014-02-21-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch f33b9bd3 [arm: omap3: Enable clocks for peripherals only if they are used] breaks SPL booting on tao3530. Since some gpio input's are read to detect the board revision. But with this patch above, the clocks to the GPIO subsystems are not enabled per default any more. The GPIO banks need to be configured specifically now. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Michael Trimarchi <michael@amarulasolutions.com> Reviewed-by: Stefano Babic <sbabic@denx.de>
| | | * ARM: AM43xx: GP-EVM: Correct GPIO used for VTT regulator controlDave Gerlach2014-02-21-15/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Schematic indicates GPIO5_7 is to be used for VTT regulator control rather than GPIO0_21 so modify enable_vtt_regulator to reflect this. Without this some boards will experience DDR3 corruption and fail to boot. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> [trini: Rework patch against mainline] Signed-off-by: Tom Rini <trini@ti.com>