summaryrefslogtreecommitdiff
path: root/include/configs
Commit message (Collapse)AuthorAgeLines
...
| | * | arm: atmel: sama5d3: add spi spl boot supportBo Shen2014-03-09-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add SPI SPL boot support for sama5d3xek board. Signed-off-by: Bo Shen <voice.shen@atmel.com> Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
| | * | ARM: atmel: add sama5d3 Xplained board supportBo Shen2014-03-09-0/+203
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add sama5d3 Xplained board support which use Atmel SAMA5D36 SoC. Now it supports boot from NAND flash and SD/MMC card. Features support: - NAND flash - SD/MMC card - Two USB hosts - Ethernet (one GMAC, one EMAC) Signed-off-by: Bo Shen <voice.shen@atmel.com> [reorder boards.cfg] Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
| | * | at91sam9263ek: add mmc supportAndreas Henriksson2014-03-09-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for using the Atmel MCI driver on at91sam9263ek. This change is modeled after the existing at91sam9260ek support. Please note that this hooks up slot1 (MCI1) for SD. Not both. Tested with at91bootstrap and u-boot on dataflash in slot 0 and fat-formatted 8GB SDHC in slot 1 on first revision at91sam9263ek (which must use dataflash in slot0 to boot). CONFIG_ATMEL_MCI_PORTB not tested. Signed-off-by: Andreas Henriksson <andreas.henriksson@endian.se> [remove empty line] Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
| | * | Merge branch 'u-boot-tegra/master' into 'u-boot-arm/master'Albert ARIBAUD2014-03-07-46/+67
| | |\ \
| | | * | ARM: tegra: implement bootcmd_pxeStephen Warren2014-03-05-1/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This retrieves a PXE config file over the network, and executes it. This allows an extlinux config file to be retrieved over the network and executed, whereas the existing bootcmd_dhcp retrieves a U-Boot script. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| | | * | ARM: tegra: rework boot scriptsStephen Warren2014-03-05-9/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update the common Tegra boot scripts in the default environment to a) Make use of the new "test -e" shell command to avoid some error messages. b) Allow booting using the sysboot command and extlinux.conf. This allows easy creation of boot menus, and provides a simple interface for distros to parameterize/configure the boot process. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| | | * | ARM: tegra: convert tegra to use distro defaultsStephen Warren2014-03-05-16/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Modify all Tegra boards to include the "distro defaults" header, so that all the config options distros expect are enabled. Remove any #defines that enable the same options from the Tegra files. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| | | * | ARM: tegra: set CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTSStephen Warren2014-03-05-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tegra's EHCI controllers only have a single PORTSC register. Configure U-Boot to know this. This prevents e.g. ehci_shutdown() from touching non-existent registers. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| | | * | ARM: tegra: move CONFIG_TEGRAnnStephen Warren2014-03-05-20/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | <asm/arch-tegra/tegra.h> needs to use CONFIG_TEGRA* to conditionalize some definitions, since some modules moved between generations. Move the definition of CONFIG_TEGRAnn to a header that's included earlier, so that it's set by the time tegra.h needs to use it. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| | * | | 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
| |\
generated by cgit v1.1 at 2024-10-09 01:20:26 +0000