summaryrefslogtreecommitdiff
path: root/include/configs
Commit message (Collapse)AuthorAgeLines
...
| | * | | OMAP3: igep00x0: Enable required clocks for GPIO that are used.Enric Balletbo i Serra2014-03-06-0/+5
| | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enable required clocks for GPIO to fix a boot issue introduced by commit f33b9bd3984fb11e1d8566a866adc5957b1e1c9d (arm: omap3: Enable clocks for peripherals only if they are used). Without this patch the u-boot freezes after the following messages OMAP36XX/37XX-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz IGEPv2 + LPDDR/NAND I2C: ready DRAM: 512 MiB NAND: 512 MiB MMC: OMAP SD/MMC: 0 Diving into the issue, the sequence that produces the u-boot freezes is setup_net_chip |--> gpio_direction_out |--> _set_gpio_dataout |--> __raw_writel To avoid this we just need enable the clocks for GPIOs that are used, but it would be interesting implement a mechanism to protect these situations and make sure that the clock is enabled when we request a GPIO. Signed-off-by: Enric Balletbo i Serra <eballetbo@gmail.com>
| * | | m68k: Remove M5271EVB and idmr board supportMasahiro Yamada2014-03-10-474/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CONFIG_SYS_HZ must be always 1000, but M5271EVB.h defines it as 1000000 and idmr.h defines it as (50000000 / 64). When compiling these two boards, a warning message is displayed: time.c:14:2: warning: #warning "CONFIG_SYS_HZ must be 1000 and should not be defined by platforms" [-Wcpp] There are no board maintainers for them so this commit just deletes them. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Jason Jin <Jason.jin@freescale.com>
| * | | Merge branch 'master' of git://git.denx.de/u-boot-mpc85xxTom Rini2014-03-07-4/+808
| |\ \ \
| | * | | powerpc/t104xrdb: Update DDR initialization related settingsPriyanka Jain2014-03-07-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update following DDR related settings for T1040RDB, T1042RDB_PI -Correct number of chip selects to two as t1040 supports two Chip selects. -Update board_specific_parameters udimm structure with settings derived via calibration. -Update ddr_raw_timing sructure corresponding to DIMM. -Set ODT to off. Typically on FSL board, ODT is set to 75 ohm, but on T104xRDB, on setting this , DDR instability is observed. Board-level debugging is in progress. Verified the updated settings to be working fine with dual-ranked Micron, MT18KSF51272AZ-1G6 DIMM at data rate 1600MT/s. Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com> Signed-off-by: York Sun <yorksun@freescale.com>
| | * | | powerpc/t1040qds: Add Video - HDMI supportPriyanka Jain2014-03-07-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | T1040 has internal display interface unit (DIU) for driving video. T1040QDS supports video mode via -LCD using TI enconder -HDMI type interface via HDMI encoder Chrontel, CH7301C encoder which is I2C programmable is used as HDMI connector on T1040QDS. This patch add support to -enable Video interface for T1040QDS -route qixis multiplexing to enable DIU-HDMI interface on board -program DIU pixel clock gerenartor for T1040 -program HDMI encoder via I2C on board Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
| | * | | powerpc/t2080rdb: Add T2080PCIe-RDB board supportShengzhou Liu2014-03-07-0/+779
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | T2080PCIe-RDB is a Freescale Reference Design Board that hosts the T2080 SoC. It works in two mode: standalone mode and PCIe endpoint mode. T2080PCIe-RDB Feature Overview ------------------------------ Processor: - T2080 SoC integrating four 64-bit dual-threads e6500 cores up to 1.8GHz DDR Memory: - Single memory controller capable of supporting DDR3 and DDR3-LP devices - 72bit 4GB DDR3-LP SODIMM in slot Ethernet interfaces: - Two 10M/100M/1G RGMII ports on-board - Two 10Gbps SFP+ ports on-board - Two 10Gbps Base-T ports on-board Accelerator: - DPAA components consist of FMan, BMan, QMan, PME, DCE and SEC SerDes 16 lanes configuration: - SerDes-1 Lane A-B: to two 10G XFI fiber (MAC9 & MAC10) - SerDes-1 Lane C-D: to two 10G Base-T (MAC1 & MAC2) - SerDes-1 Lane E-H: to PCIe Goldfinger (PCIe4 x4, Gen3) - SerDes-2 Lane A-D: to PCIe Slot (PCIe1 x4, Gen2) - SerDes-2 Lane E-F: to C293 secure co-processor (PCIe2 x2) - SerDes-2 Lane G-H: to SATA1 & SATA2 IFC/Local Bus: - NOR: 128MB 16-bit NOR flash - NAND: 512MB 8-bit NAND flash - CPLD: for system controlling with programable header on-board eSPI: - 64MB N25Q512 SPI flash USB: - Two USB2.0 ports with internal PHY (both Type-A) PCIe: - One PCIe x4 gold-finger - One PCIe x4 connector - One PCIe x2 end-point device (C293 Crypto co-processor) SATA: - Two SATA 2.0 ports on-board SDHC: - support a TF-card on-board I2C: - Four I2C controllers. UART: - Dual 4-pins UART serial ports Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
| | * | | powerpc/t208xqds: fixup for t208xqdsShengzhou Liu2014-03-07-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change QIXIS timing parameter CONFIG_SYS_CS3_FTIM2 to 8 from 0. Fix EMI2 for t2080qds, which was caused by adding t2081qds. Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
| * | | | powerpc: mpc8260: consolidate CONFIG_MPC8260 and CONFIG_8260Masahiro Yamada2014-03-07-25/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this commit, CONFIG_MPC8260 and CONFIG_8260 were used mixed-up. All boards with mpc8260 cpu defined both of them: - CONFIG_MPC8260 was defined in board config headers and include/common.h - CONFIG_8260 was defined arch/powerpc/cpu/mpc8260/config.mk We do not need to have both of them. This commit keeps only CONFIG_MPC8260. This commit does: - Delete CONFIG_8260 and CONFIG_MPC8260 definition in config headers and include/common.h - Rename CONFIG_8260 to CONFIG_MPC8260 in arch/powerpc/cpu/mpc8260/config.mk. - Rename #ifdef CONFIG_8260 to #ifdef CONFIG_MPC8260 Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Wolfgang Denk <wd@denx.de>
| * | | | mips: move CONFIG_MIPS{32, 64} definition to config.mkMasahiro Yamada2014-03-07-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All mips32 boards define CONFIG_MIPS32 in config headers except malta boards which define it in boards.cfg. We can consolidate them by defining it in arch/mips/cpu/mips32/config.mk. CONFIG_MIPS64 definition can be moved to arch/mips/cpu/mips64/config.mk as well. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Acked-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
| * | | | kbuild: add CONFIG_ prefix to USE_PRIVATE_LIBGCCMasahiro Yamada2014-03-07-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this commit, USE_PRIVATE_LIBGCC was defined in arch-specific config.mk and referenced in arch/$(ARCH)/lib/Makefile. We are not happy about parsing config.mk again and again. We have to keep the same behavior with a different way. By adding "CONFIG_" prefix, this macro appears in include/autoconf.mk, include/spl-autoconf.mk. (And treating USE_PRIVATE_LIBGCC as CONFIG macro is reasonable enough.) Tegra SoC family defined USE_PRIVATE_LIBGCC as "yes" in arch/arm/cpu/arm720t/tegra*/config.mk, whereas did not define it in arch/arm/cpu/armv7/tegra*/config.mk. It means Tegra enables PRIVATE_LIBGCC only for SPL. We can describe the same behavior by adding #ifdef CONFIG_SPL_BUILD # define CONFIG_USE_PRIVATE_LIBGCC #endif to include/configs/tegra-common.h. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Tom Warren <twarren@nvidia.com> Cc: Simon Glass <sjg@chromium.org> Acked-by: Stephen Warren <swarren@nvidia.com>
| * | | | kbuild, blackfin: Add CONFIG_CC_OPTIMIZE_LIBS_FOR_SPEEDMasahiro Yamada2014-03-07-16/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many (but not all) of Blackfin boards give -O2 option to compile under lib/ directory. That means lib/ should be speed-optimized, whereas other parts should be size-optimized. We want to keep the same behavior, but do not want to parse board/*/config.mk again and again. We've got no choice but to invent a new method. CONFIG_CC_OPTIMIZE_LIBS_FOR_SPEED, if it is enabled, gives -O2 flag only for building under lib/ directory. Dirty codes which I had marked as "FIX ME" in board/${BOARD}/config.mk have been deleted. Instead, CONFIG_CC_OPTIMIZE_LIBS_FOR_SPEED has been defined in include/configs/${BOARD}.h. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Sonic Zhang <sonic.zhang@analog.com>
| * | | | ppc4xx: Remove 4xx NAND booting supportStefan Roese2014-03-07-483/+4
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As ppc4xx currently only supports the deprecated nand_spl infrastructure and nobody seems to have time / resources to port this over to the newer SPL infrastructure, lets remove NAND booting completely. This should not affect the "normal", non NAND-booting ppc4xx platforms that are currently supported. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: Tirumala Marri <tmarri@apm.com> Cc: Matthias Fuchs <matthias.fuchs@esd.eu> Cc: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Tom Rini <trini@ti.com> Tested-by: Matthias Fuchs <matthias.fuchs@esd.eu>
| * | | Merge branch 'master' of git://git.denx.de/u-boot-nand-flashTom Rini2014-03-04-26/+0
| |\ \ \
| | * | | mtd: nand: omap: remove unused #defines from common omap_gpmc.hpekon gupta2014-03-04-26/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OMAP NAND driver can detect Page-size and OOB-size of NAND device from ONFI params or nand_id[] table. And based on that it defines ECC layout. This patch 1) removes following board configs used for defining NAND ECC layout - GPMC_NAND_ECC_LP_x16_LAYOUT (for large page x16 NAND) - GPMC_NAND_ECC_LP_x8_LAYOUT (for large page x8 NAND) - GPMC_NAND_ECC_SP_x16_LAYOUT (for small page x16 NAND) - GPMC_NAND_ECC_SP_x8_LAYOUT (for small page x8 NAND) 2) removes unused #defines in common omap_gpmc.h depending on above configs Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5 Signed-off-by: Pekon Gupta <pekon@ti.com>
| * | | | sandbox: Convert GPIOs to use driver modelSimon Glass2014-03-04-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert sandbox over to use driver model GPIOs. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | | dm: Add a demonstration/example driverSimon Glass2014-03-04-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As an example of how to write a uclass and a driver, provide a demo version of each, accessible through the 'demo' command. To use these with driver model, define CONFIG_CMD_DEMO and CONFIG_DM_DEMO. The two demo drivers are enabled with CONFIG_DM_DEMO_SIMPLE and CONFIG_DM_DEMO_SHAPE. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Pavel Herrmann <morpheus.ibis@gmail.com> Signed-off-by: Viktor Křivák <viktor.krivak@gmail.com> Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>
| * | | | dm: Add a 'dm' command for testingSimon Glass2014-03-04-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This command is not required for driver model operation, but can be useful for testing. It provides simple dumps of internal data structures. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Pavel Herrmann <morpheus.ibis@gmail.com> Signed-off-by: Viktor Křivák <viktor.krivak@gmail.com> Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>
| * | | | dm: Add basic testsSimon Glass2014-03-04-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | | sandbox: config: Enable driver modelSimon Glass2014-03-04-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use driver model in sandbox to permit running of driver model unit test. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | | sandbox: Build a device tree file for sandboxSimon Glass2014-03-04-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for building a device tree for sandbox's CONFIG_OF_HOSTFILE option to make it easier to use device tree with sandbox. This adjusts the Makefile to build a u-boot.dtb file which can be passed to sandbox U-Boot with: ./u-boot -d u-boot.dtb Signed-off-by: Simon Glass <sjg@chromium.org>
| * | | | sizes.h - consolidate for all architecturesAlexey Brodkin2014-03-04-28/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Copied from Linux sources "include/linux/sizes.h" commit 413541dd66d51f791a0b169d9b9014e4f56be13c Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Tom Rini <trini@ti.com> Cc: Stefan Roese <sr@denx.de> Cc: Albert Aribaud <albert.u.boot@aribaud.net> Acked-by: Tom Rini <trini@ti.com> Acked-by: Stefan Roese <sr@denx.de> [trini: Add bcm Kona platforms to the patch] Signed-off-by: Tom Rini <trini@ti.com>
| * | | | zynq: Do not use SPL OF initializationMichal Simek2014-03-04-0/+1
| |/ / / | | | | | | | | | | | | | | | | | | | | Disable CONFIG_OF_CONTROL for SPL compilation. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
* | | | mx6: add example DTB for mx6qsabreautoStefano Babic2014-04-02-0/+3
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Stefano Babic <sbabic@denx.de> CC: Fabio Estevam <fabio.estevam@freescale.com>
* | | | arm: mx5: Avoid hardcoding memory sizes on M53EVKMarek Vasut2014-03-31-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | 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/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Adjust the load address of U-Boot and SPL for HABMarek Vasut2014-03-31-1/+9
| |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+425
| |/ |/| | | | | | | | | | | | | | | 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>
* | arm: am335x: DXR2: Reset SMSC LAN9303 switch via GPIO upon bootupStefan Roese2014-03-04-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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: Add Ethernet boot support to SPLMugunthan V N2014-03-04-2/+8
| | | | | | | | | | | | | | Add Ethernet Boot support to SPL 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/+1
| | | | | | | | | | | | | | | | | | 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-0/+20
| | | | | | | | | | | | | | | | 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>
* | drivers: net: cpsw: add support to have phy address from cpsw platform dataMugunthan V N2014-03-04-11/+0
|/ | | | | | | | | | | | 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-43/+1077
|\ | | | | | | | | | | | | | | | | 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>
| * Merge branch 'u-boot-ti/master' into 'u-boot-arm/master'Albert ARIBAUD2014-02-24-12/+849
| |\
| | * 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>
| | * 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: 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>
| | * Add support for B&R KWB MotherboardHannes Petermaier2014-02-21-0/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds support for Bernecker & Rainer Industrieelektronik GmbH KWB Motherboard, using TI's AM3352 SoC. Most of code is derived from TI's AM335x_EVM Signed-off-by: Hannes Petermaier <oe5hpm@oevsv.at> Cc: trini@ti.com
generated by cgit v1.1 at 2024-12-24 16:30:20 +0000