summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeLines
* arm: omap3: devkit8000: inherit from ti_armv7_common.hAnthoine Bourgeois2015-01-13-98/+36
|
* pcm051: Add boot script support to pcm051matwey.kornilov@gmail.com2015-01-13-11/+18
| | | | | | This patch adds boot script support to pcm051 Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>
* board: ti: am43xx: add support for AM43xx Industrial Development KitFelipe Balbi2015-01-13-19/+118
| | | | | | | | | | | | AM43xx Industrial Development Kit is a new board based on AM437x line of SoCs. Targetted at Industrial Automation applications, it comes with EtherCAT, motor control and other goodies. Thanks to James Doublesin for all the help. Cc: James Doublesin <doublesin@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
* pmic: add tps62362 simple wrapper codeFelipe Balbi2015-01-13-0/+77
| | | | | | | | This regulator is used with AM437x IDK to feed VDD_MPU, without means to scale VDD_MPU we can't support higher frequencies. Signed-off-by: Felipe Balbi <balbi@ti.com>
* board: ti: am43xx: take care of all OPPsFelipe Balbi2015-01-13-0/+9
| | | | | | | | | | | | | | Make sure that all OPPs are checked on scale_vcores(). While at that also fix 600MHz VDD_MPU voltage according to AM437x Data Manual available at [1]. Table 5-3 on that document, lists all valid voltages per frequency. [1] http://www.ti.com/lit/ds/symlink/am4379.pdf Signed-off-by: Felipe Balbi <balbi@ti.com>
* power: tps65218: define all valid VDD_MPU voltagesFelipe Balbi2015-01-13-0/+3
| | | | | | | | DCDC1 is used as VDD_MPU in all known boards, let's define all other valid voltages for that rail so it can be used by our boards. Signed-off-by: Felipe Balbi <balbi@ti.com>
* board: ti: am43xx: replace if else if else with a switchFelipe Balbi2015-01-13-3/+6
| | | | | | | | A switch statement fits better in this case, specially considering we have a few extra frequencies to use. Signed-off-by: Felipe Balbi <balbi@ti.com>
* arm: am437x: Correct PLL frequency for 25MHzJames Doublesin2015-01-13-1/+1
| | | | | | | | The frequencies for 25MHz in dpll_per were out of spec for 25MHz, correct. Signed-off-by: James Doublesin <doublesin@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
* arm: am437x: Enable hardware leveling for EMIFJames Doublesin2015-01-13-207/+138
| | | | | | | | | | | | Switch to using hardware leveling for certain parameters on the EMIF rather than using precalculated values. Doing this also means we have a common place now between am437x and am335x for setting emif_sdram_ref_ctrl with a value for the correct delay length. Tested-by: Felipe Balbi <balbi@ti.com> Tested-by: Tom Rini <trini@ti.com> Signed-off-by: James Doublesin <doublesin@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
* arm: am437x: PLL values for all input frequenciesJames Doublesin2015-01-13-26/+33
| | | | | | | | | | Need to provide PLL values for all possible input frequencies (19.2, 24, 25, 26MHz). Values provide are also optimized for jitter (needed especially for PER PLL and DDR PLL). Signed-off-by: James Doublesin <doublesin@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
* mtd: OMAP: Enable GPMC prefetch modeDaniel Mack2015-01-13-3/+122
| | | | | | | | | | | | | | | | | | | | | | | | | Enable GPMC's prefetch feature for NAND access. This speeds up NAND read access a lot by pre-fetching contents in the background and reading them through the FIFO address. The current implementation has two limitations: a) it only works in 8-bit mode b) it only supports read access Both is easily fixable by someone who has hardware to implement it. Note that U-Boot code uses non word-aligned buffers to read data into, and request read lengths that are not multiples of 4, so both partial buffers (head and tail) have to be addressed. Tested on AM335x hardware. Tested-by: Guido Martínez <guido@vanguardiasur.com.ar> Reviewed-by: Guido Martínez <guido@vanguardiasur.com.ar> Signed-off-by: Daniel Mack <zonque@gmail.com> [trini: Make apply again, use 'cs' fix pointed out by Guido] Signed-off-by: Tom Rini <trini@ti.com>
* Prepare v2015.01Tom Rini2015-01-12-1/+1
| | | | Signed-off-by: Tom Rini <trini@ti.com>
* Nokia RX-51: Do not call secure PPA routine on non secure devicesPali Rohár2015-01-12-1/+5
| | | | | | | | | | | | | Since commit 41623c91b09a0c865fab41acdaff30f060f29ad6 u-boot running in qemu is crashing in function do_omap3_emu_romcode_call(). RX-51 board uses this function for Cortex-A8 errata 430973 workaround (Set IBE bit in ACR) which is needed only on real secure device and not in qemu. This board patch just disable calling secure PPA routine on non secure devices. Qemu implements GP device and with this patch u-boot is working in qemu again. Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz>
* powerpc: xes: Add maintainerPeter Tyser2015-01-12-4/+4
| | | | | | Add Peter Tyser as the maintainer of Extreme Engineering Solutions products. Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
* powerpc: xes: Convert to generic boardJohn Schmoller2015-01-12-0/+10
| | | | | | | | Convert Extreme Engineering Solutions products to use generic board support. Signed-off-by: John Schmoller <jschmoller@xes-inc.com> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
* ARM: remove redudant information from Kconfig filesMasahiro Yamada2015-01-12-30/+0
| | | | | | | | | - "string" type for SYS_* is defined in arch/Kconfig - SYS_CPU "armv7" has been replaced with "select CPU_V7" - SYS_SOC "tegra124" is already defined in tegra124/Kconfig Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Bo Shen <voice.shen@atmel.com>
* omap: beagle_x15: add MAINTAINERSMasahiro Yamada2015-01-12-0/+6
| | | | | | | | Commit 1e4ad74b875f (beagle_x15: add board support for Beagle x15) missed to add board/ti/beagle_x15/MAINTAINERS. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Felipe Balbi <balbi@ti.com>
* stv0991: record defconfig ownership in MAINTAINERSMasahiro Yamada2015-01-12-0/+1
| | | | | | | | This commit fixes warnings reported by tools/genboardscfg.py. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Vikas Manocha <vikas.manocha@st.com> Acked-by: Vikas Manocha <vikas.manocha@st.com>
* ARM: kirkwood: dns325: Add generic board supportStefan Herbrechtsmeier2015-01-12-0/+1
| | | | Signed-off-by: Stefan Herbrechtsmeier <stefan@herbrechtsmeier.net>
* Change e-mail address of Stefan HerbrechtsmeierStefan Herbrechtsmeier2015-01-12-6/+6
| | | | Signed-off-by: Stefan Herbrechtsmeier <stefan@herbrechtsmeier.net>
* common/board_f.c: fix compile error when tracing disabledKevin Hilman2015-01-12-7/+0
| | | | | | | | | | | | | | | | When CONFIG_TRACE is disabled, linking fails with: common/built-in.o:(.data.init_sequence_f+0x8): undefined reference to `trace_early_init' To fix, wrap trace init calls with #ifdef CONFIG_TRACE. While at it, remove the static inline version of the init call from trace.h as suggested by Simon Glass, since it doesnt work. Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@ti.com> Signed-off-by: Kevin Hilman <khilman@linaro.org> Acked-by: Simon Glass <sjg@chromium.org>
* tools/kwbimage.c: fix parser error handlingAndreas Bießmann2015-01-11-6/+8
| | | | | | | | | | | | | | | | | | | | The two error checks for image_boot_mode_id and image_nand_ecc_mode_id where wrong and would never fail, fix that! This was detected by Apple's clang compiler: ---8<--- HOSTCC tools/kwbimage.o tools/kwbimage.c:553:20: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] if (el->bootfrom < 0) { ~~~~~~~~~~~~ ^ ~ tools/kwbimage.c:571:23: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] if (el->nandeccmode < 0) { ~~~~~~~~~~~~~~~ ^ ~ 2 warnings generated. --->8--- Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com> Acked-By: Jeroen Hofstee <jeroen@myspectrum.nl>
* ARM: atmel: sama5d3xek: fix the LCD parametersBo Shen2015-01-11-2/+1
| | | | | | Remove unused vsync parameter, and correct the include file. Signed-off-by: Bo Shen <voice.shen@atmel.com>
* ARM: atmel: sama5d4xek: fix the LCD parametersBo Shen2015-01-11-2/+1
| | | | | | Remove unused vsync parameter, and correct the include file. Signed-off-by: Bo Shen <voice.shen@atmel.com>
* ARM: atmel: sama5d4 xplained: fix the LCD parametersBo Shen2015-01-11-4/+2
| | | | | | | Correct the LCD pixel clock, remove unused vsync parameter, and also correct the include file. Signed-off-by: Bo Shen <voice.shen@atmel.com>
* fix: tools: kwbimage.c: Initialize headersz to suppress warningŁukasz Majewski2015-01-10-1/+1
| | | | | | | | | | | | | | | | When building with my toolchain (4.8.2): CROSS_COMPILE=/home/lukma/work/ptxdist/toolchains/arm/OSELAS.Toolchain-2013.12.0/arm-v7a-linux-gnueabi/gcc-4.8.2-glibc-2.18-binutils-2.24-kernel-3.12-sanitized/bin/arm-v7a-linux-gnueabi- I see following WARNING: tools/kwbimage.c: In function "kwbimage_set_header": tools/kwbimage.c:803:8: warning: "headersz" may be used uninitialized in this function [-Wmaybe-uninitialized] memcpy(ptr, image, headersz); ^ This fix aims to suppress it. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Acked-by: Stefan Roese <sr@denx.de> Acked-by: Heiko Schocher <hs@denx.de>
* Merge git://git.denx.de/u-boot-nand-flashTom Rini2015-01-10-10/+5
|\
| * mtd: nand: do not scan BBT after scrubMasahiro Yamada2015-01-09-8/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, "nand scrub" runs chip->scan_bbt at the end of nand_erase_opts() even if NAND_SKIP_BBTSCAN flag is set. It violates the intention of NAND_SKIP_BBTSCAN. Move NAND_SKIP_BBTSCAN flag check to nand_block_checkbad() so that chip->scan_bbt() is never run if NAND_SKIP_BBTSCAN is set. Also, unset NAND_BBT_SCANNED flag instead of running chip->scan_bbt() right after scrub. We can be lazier here because the BBT is scanned at the next call of nand_block_checkbad(). Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Scott Wood <scottwood@freescale.com>
| * mtd: nand: Mark the BBT as scanned prior to calling scan_bbt againMasahiro Yamada2015-01-09-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 35c204d8a9d0 (nand: reinstate lazy bad block scanning) broke NAND_BBT_USE_FLASH feature. Its git-log claimed that it reinstated the change as by commit fb49454b1b6c ("nand: reinstate lazy bad block scanning"), but it moved "chip->options |= NAND_BBT_SCANNED" below "chip->scan_bbt(mtd);". It causes recursion if scan_bbt does not find a flash based BBT and tries to write one, and the attempt to erase the BBT area causes a bad block check. Reinstate commit ff49ea8977b5 (NAND: Mark the BBT as scanned prior to calling scan_bbt.). Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Rostislav Lisovy <lisovy@merica.cz> Cc: Heiko Schocher <hs@denx.de> Cc: Scott Wood <scottwood@freescale.com>
| * mtd: nand: revive "nand scrub" commandMasahiro Yamada2015-01-09-1/+1
| | | | | | | | | | | | | | | | | | Since commit ff94bc40af34 (mtd, ubi, ubifs: resync with Linux-3.14), the "nand scrub" command has not been working. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Scott Wood <scottwood@freescale.com> Cc: Heiko Schocher <hs@denx.de>
* | arc: introduce "mdbtrick" targetAlexey Brodkin2015-01-09-0/+15
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MetaWare debugger (MDB) is still used as a primary tool for interaction with target via JTAG. Moreover some very advanced features are not yet implemented in GDB for ARC (and not sure if they will be implemnted sometime soon given complexity and rare need for those features for common user). So if we're talking about development process when U-Boot is loaded in target memory not by low-level boot-loader but manually through JTAG chances are high developer uses MDB for it. But MDB doesn't support PIE (position-independent executable) - it will refuse to even start - that means no chance to load elf contents on target. Then the only way to load U-Boot in MDB is to fake it by: 1. Reset PIE flag in ELF header This is simpe - on attempt to open elf MDB checks header and if it doesn't match its expectation refuces to use provided elf. 2. Strip all debug information from elf If (1) is done then MDB will open elf but on parsing of elf's debug info it will refuse to process due to debug info it cannot understand (symbols with PIE relocation). Even though it could be done manually (I got it documented quite a while ago here http://www.denx.de/wiki/U-Boot/ARCNotes) having this automated way is very convenient. User may build U-Boot that will be loaded on target via MDB saying "make mdbtrick". Then if we now apply the manipulation MDB will happily start and will load all required sections into the target. Indeed there will be no source-level debug info available. But still MDB will do its work on showing disassembly, global symbols, registers, accessing low-level debug facilities etc. As a summary - this is a pretty dirty hack but it simplifies life a lot for us ARc developers. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Tom Rini <trini@ti.com> Cc: Wolfgang Denk <wd@denx.de>
* arm: vf610: fix boot from SD-cardStefan Agner2015-01-09-1/+4
| | | | | | | | | | | | | | | | Boot from SD-card (and probably also from NAND) was broken since commit d6d07a9bec ("arm: vf610: add NAND support for vf610twr"). It looks like the increased size of U-Boot lead to a situation where the boot ROM overwrote its own stack/heap while loading U-Boot from the SD-card to the SRAM. However, U-Boot worked fine when loaded through USB serial loader directly into SRAM. It looks like loading from SD-card uses other stack/heap location then the serial loader (or maybe no stack or heap at all). This fix moves U-Boot to gfxRAM, which is 512kB in size and is not used by the boot ROM nor the SD-card loader of it. Signed-off-by: Stefan Agner <stefan@agner.ch> Acked-by: Bill Pringlemeir <bpringlemeir@nbsps.com>
* arm: build arch memset/memcpy in Thumb2 modeStefan Agner2015-01-09-87/+142
| | | | | | | | | | | | | | | | | | | | | | Resynchronize memcpy/memset with kernel 3.17 and build them in Thumb2 mode (unified syntax). Those assembler files can be built and linked in ARM mode too, however when calling them from Thumb2 built code, the stack got corrupted and the copy did not succeed (the exact details have not been traced back). However, the Linux kernel builds those files in Thumb2 mode. Hence U-Boot should build them in Thumb2 mode too when CONFIG_SYS_THUMB_BUILD is set. To build the files without warning, some assembler instructions had to be replaced with their UAL compliant variant (thanks Jeroen for this input). To build the file in Thumb2 mode the implicit-it=always option need to be set to generate Thumb2 compliant IT instructions where needed. We add this option to the general AFLAGS when building for Thumb2. Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Signed-off-by: Stefan Agner <stefan@agner.ch>
* Merge branch 'master' of git://git.denx.de/u-boot-spiTom Rini2015-01-08-58/+316
|\
| * imx:mx6sxsabresd support qspi AHB readPeng Fan2015-01-09-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add CONFIG_SYS_FSL_QSPI_AHB in header file to enable AHB in driver. In order to count the time, add CONFIG_CMD_TIME. Using AHB read can improve the the read speed about 30%. AHB read: => time sf read 0x8f800000 0 100000 SF: 1048576 bytes @ 0x0 Read: OK time: 0.174 seconds => time sf read 0x8f800000 1000000 100000 SF: 1048576 bytes @ 0x1000000 Read: OK time: 0.174 seconds IP read: => time sf read 0x8f800000 0 100000 SF: 1048576 bytes @ 0x0 Read: OK time: 0.227 seconds => time sf read 0x8f800000 1000000 100000 SF: 1048576 bytes @ 0x1000000 Read: OK time: 0.227 seconds Note: Quad read is not supported in driver, now. In my side, using AHB and Quad read can achieve about 16MB/s. Anyway, I have plan to reimplement the driver using DTB and DM, then make the code cleaner and more feature can be added. Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
| * qspi:fsl implement AHB readPeng Fan2015-01-09-10/+142
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The QSPI controller in i.MX 6SoloX and Vybrid supports reading data using IP register and AHB bus. The original driver only supports reading data from IP interface. The IC team suggests to use AHB read which is faster then IP read. Using AHB read, we can directly memcpy, a "missed" access to the buffer will cause the controller to clear the buffer and use the SEQID stored in bfgencr register to initiate a read from flash device. Since AHB bus is 64 bit width, we can not set MCR register using 32bit. In order to minimize code change, redefine QSPI_MCR_END_CFD_LE to 64bit Little endian but not 32bit Little endia. Introduce a new configuration option CONFIG_SYS_FSL_QSPI_AHB. If want to use AHB read, just define CONFIG_SYS_FSL_QSPI_AHB. If not, just ignore it. Actually if Vybrid is migrated to use AHB read, this option can be removed and IP read function can be discared. The reason to introduce this option is that only i.MX SOC is tested in my side, no Vybrid platform for me. In spi_setup_slave, the original piece code to set AHB is deleted, since Vybrid platform does not use this to intiate AHB read. Instead, add qspi_init_ahb_read function if defined CONFIG_SYS_FSL_QSPI_AHB. Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
| * spi: ftssp010_spi: Simplify code flow in ftssp010_[wait|wait_tx|wait_rx]Axel Lin2015-01-08-24/+12
| | | | | | | | | | | | | | No functional change, just simplify the code a bit. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
| * spi: cadence_qspi: Fix checking return value of fdt_first_subnode()Axel Lin2015-01-07-1/+1
| | | | | | | | | | | | | | | | fdt_first_subnode() returns -FDT_ERR_NOTFOUND if no subnode found. 0 is supposed to be a valid offset returns from fdt_first_subnode(). Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
| * mx6sxsabresd: support qspi flash bigger than 16MBPeng Fan2015-01-07-0/+5
| | | | | | | | | | | | | | | | | | | | | | mx6sxsabresd revb board uses 32MB qspi flash, reva board uses 16MB qspi flash. Currently, the default supported platform is revb board. If want to configure for reva board, just define CONFIG_MX6SX_SABRESD_REVA in mx6sxsabresd.h to support reva qspi flashes whose size is 16MB. Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
| * spi:fsl-quadspi support bank register read writePeng Fan2015-01-07-15/+145
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To support bigger than 16MB size qspi flashes, spi framework uses bank switch to access higher bank or lower bank. In this patch, QSPI_CMD_BRRD, QSPI_CMD_BRWR, QSPI_CMD_WREAR, QSPI_CMD_RDEAR is initialized in LUT register with related pad and length configuration. qspi_op_pp is originally for page programming, this patch reuses this function for bank register switch and renamed it with qspi_op_write. Since bank or EAR register is only 1 byte length, however original qspi_op_pp or now renamed qspi_op_write only support 4 bytes lenght as the access unit, this will trigger data abort exception when access EAR or bank register. This is because upper framework passes a 1 bytes pointer to qspi_op_write, however qspi_op_write treat it as an int pointer. This patch fixes this for accessing EAR or bank register. Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
| * dt: socfpga: Replace num-chipselect with num-csMarek Vasut2015-01-07-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | This optional DT property is called 'num-cs', so repair the misnomers. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Chin Liang See <clsee@opensource.altera.com> Cc: Dinh Nguyen <dinguyen@opensource.altera.com> Cc: Pavel Machek <pavel@denx.de> Cc: Stefan Roese <sr@denx.de> Cc: Vince Bridgers <vbridger@opensource.altera.com> Acked-by: Pavel Machek <pavel@denx.de> Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
| * dt: socfpga: Rename snps, dw-spi-mmio to snps, dw-apb-ssiMarek Vasut2015-01-06-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linux now also contains SPI driver, yet the name is 'snps,dw-apb-ssi'. Fix the naming before we have to support both names. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Chin Liang See <clsee@opensource.altera.com> Cc: Dinh Nguyen <dinguyen@opensource.altera.com> Cc: Pavel Machek <pavel@denx.de> Cc: Stefan Roese <sr@denx.de> Cc: Vince Bridgers <vbridger@opensource.altera.com> Reviewed-by: Stefan Roese <sr@denx.de> Acked-by: Pavel Machek <pavel@denx.de> Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
| * spi: designware_spi: Fix detecting FIFO depthAxel Lin2015-01-06-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current code tries to find the highest valid fifo depth by checking the value it wrote to DW_SPI_TXFLTR. There are a few problems in current code: 1) There is an off-by-one in dws->fifo_len setting because it assumes the latest register write fails so the latest valid value should be fifo - 1. 2) We know the depth could be from 2 to 256 from HW spec, so it is not necessary to test fifo == 257. In the case fifo is 257, it means the latest valid setting is fifo = 256. So after the for loop iteration, we should check fifo == 2 case instead of fifo == 257 if detecting the FIFO depth fails. This patch fixes above issues. Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Stefan Roese <sr@denx.de> Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
* | mx25: Fix boot hang by avoiding vector relocationFabio Estevam2015-01-08-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 3ff46cc42b9d73d0 ("arm: relocate the exception vectors") mx25pdk hangs like this: CPU: Freescale i.MX25 rev1.2 at 399 MHz Reset cause: WDOG Board: MX25PDK I2C: ready DRAM: 64 MiB (hangs) Add a specific relocate_vectors macro that skips the vector relocation, as the i.MX25 SoC does not provide RAM at the high vectors address (0xFFFF0000), and (0x00000000) maps to ROM. This allows mx25 to boot again. Acked-By: Bill Pringlemeir <bpringlemeir@nbsps.com> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
* | doc: fix spelling errors in am335x/READMEJeremiah Mahler2015-01-08-3/+3
| | | | | | | | | | | | | | Fix several spelling errors and replace the invalid word "architectured" with "designed". Signed-off-by: Jeremiah Mahler <jmmahler@gmail.com>
* | mx25: Remove empty line after printing the reset causeFabio Estevam2015-01-08-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently there is an unneeded empty line after printing the reset cause: U-Boot 2015.01-rc4-00080-g0551a93 (Jan 06 2015 - 13:04:19) CPU: Freescale i.MX25 rev1.2 at 399 MHz Reset cause: POR Board: MX25PDK I2C: ready DRAM: 64 MiB MMC: FSL_SDHC: 0 Remove the extra "\n" when printing the reset cause. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
* | i2c:mxc fix array size of i2c_dataPeng Fan2015-01-08-11/+11
| | | | | | | | | | | | | | | | | | | | | | We should not hardcode array size of i2c_data to 3. To CONFIG_FSL_LSCH3, there are 4 i2c interface, but not 3. So the size of i2c_data array should be calculated using "ARRAY_SIZE(i2c_bases)". To avoid compile error, move i2c_bases before sram_data structure which contains i2c_data array. Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
* | MAINTAINERS: add me as a co-maintainer of KIRKWOODLuka Perkov2015-01-08-1/+3
| | | | | | | | | | | | | | Signed-off-by: Luka Perkov <luka.perkov@sartura.hr> CC: Prafulla Wadaskar <prafulla@marvell.com> CC: Wolfgang Denk <wd@denx.de> Acked-by: Stefan Roese <sr@denx.de>
* | doc/gitmail-rc: fix whitespacesLuka Perkov2015-01-08-2/+2
| | | | | | | | Signed-off-by: Luka Perkov <luka.perkov@sartura.hr>
* | gpt: Fix the protective MBR partition sizeMaxime Ripard2015-01-08-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | According to the UEFI Spec (Table 16, section 5.2.3 of the version 2.4 Errata B), the protective MBR partition record size must be set to the size of the disk minus one, in LBAs. However, the current code was setting the size as the total number of LBAs on the disk, resulting in an off-by-one error. This confused the AM335x ROM code, and will probably confuse other tools as well. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>