summaryrefslogtreecommitdiffstats
path: root/include/configs/tao3530.h
Commit message (Collapse)AuthorAgeFilesLines
* omap3: remove remnant macros GPMC_NAND_ECC_LP_x8_LAYOUT and ↵pekon gupta2014-06-061-1/+0
| | | | | | | | | | | GPMC_NAND_ECC_LP_x16_LAYOUT OMAP3 used GPMC_NAND_ECC_LP_x8_LAYOUT and GPMC_NAND_ECC_LP_x16_LAYOUT macros to configure GPMC controller for x7 or x8 bit device connected to its interface. Now this information is encoded in CONFIG_SYS_NAND_DEVICE_WIDTH macro, so above macros can be completely removed. Signed-off-by: Pekon Gupta <pekon@ti.com>
* mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device ↵pekon gupta2014-06-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | bus-width GPMC controller needs to be configured based on bus-width of the NAND device connected to it. Also, dynamic detection of NAND bus-width from on-chip ONFI parameters is not possible in following situations: SPL: SPL NAND drivers does not support ONFI parameter reading. U-boot: GPMC controller iniitalization is done in omap_gpmc.c:board_nand_init() which is called before probing for devices, hence any ONFI parameter information is not available during GPMC initialization. Thus, OMAP NAND driver expected board developers to explicitely write GPMC configurations specific to NAND device attached on board in board files itself. But this was troublesome for board manufacturers as they need to dive into lengthy platform & SoC documents to find details of GPMC registers and appropriate configurations to get NAND device working. This patch instead adds existing CONFIG_SYS_NAND_BUSWIDTH_16BIT to board config hich indicates that connected NAND device has x16 bus-width. And then based on this config GPMC driver itself initializes itself based on NAND bus-width. This keeps board developers free from knowing GPMC controller specific internals. Signed-off-by: Pekon Gupta <pekon@ti.com>
* arm: omap3: Fix tao3530/omap3_ha SPL boot hangup (GPIO clocks not enabled)Stefan Roese2014-02-211-0/+7
| | | | | | | | | | | | | | Patch f33b9bd3 [arm: omap3: Enable clocks for peripherals only if they are used] breaks SPL booting on tao3530. Since some gpio input's are read to detect the board revision. But with this patch above, the clocks to the GPIO subsystems are not enabled per default any more. The GPIO banks need to be configured specifically now. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Michael Trimarchi <michael@amarulasolutions.com> Reviewed-by: Stefano Babic <sbabic@denx.de>
* arm: omap3: Remove bootargs mem_size handlingStefan Roese2013-12-121-3/+0
| | | | | | | | | | | The memory size is autodetected and is passed to the Linux kernel either via ATAGs or device-tree (dtb). So there is no need to pass it via the bootargs. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Tapani Utriainen <tapani@technexion.com> Cc: Thorsten Eisbein <thorsten.eisbein@head-acoustics.de> Cc: Tom Rini <trini@ti.com>
* arm: omap3: Add SPL support to tao3530Stefan Roese2013-12-121-0/+65
| | | | | | | | | | | | | Add SPL support for the Technexion TAO3530 SOM to replace x-loader. Tested with the Thunder baseboard. Currently this is only tested with the TAO3530 SOM revision (Ax/Bx). Tested by booting via MMC and NAND. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Tapani Utriainen <tapani@technexion.com> Cc: Thorsten Eisbein <thorsten.eisbein@head-acoustics.de> Cc: Tom Rini <trini@ti.com>
* arm, omap3: Add support for TechNexion modulesTapani Utriainen2013-12-121-0/+301
Add support for TechNexion TAO3530 SoM This patch has been posted quite a long time ago. I ported it to the latest mainline U-Boot version. With some additional cleanup and enhancements. Signed-off-by: Tapani Utriainen <tapani@technexion.com> CC: Sandeep Paulraj <s-paulraj@ti.com> Signed-off-by: Stefan Roese <sr@denx.de> Cc: Thorsten Eisbein <thorsten.eisbein@head-acoustics.de> Cc: Tom Rini <trini@ti.com>
OpenPOWER on IntegriCloud