summaryrefslogtreecommitdiff
path: root/include/configs/omap3_igep00x0.h
Commit message (Collapse)AuthorAgeLines
* OMAP3: igep0032: Fix regression due commit f3b4bc45.Enric Balletbo i Serra2015-02-24-3/+6
| | | | | | | | | | | | | | | | | | | | Commit referenced in subject breaks IGEP0032 build with the following error: drivers/misc/status_led.c:30:7: error: 'RED_LED_GPIO' undeclared here (not in a function) scripts/Makefile.build:275: recipe for target 'drivers/misc/status_led.o' failed make[2]: *** [drivers/misc/status_led.o] Error 1 scripts/Makefile.build:420: recipe for target 'drivers/misc' failed make[1]: *** [drivers/misc] Error 2 Makefile:1093: recipe for target 'drivers' failed make: *** [drivers] Error 2 Fix this by skipping the status led on IGEP0032 machine as is not available and throw an error for future machines if the status led is not configured to avoid build breakage. Reported-by: Albert ARIBAUD <albert.u.boot@aribaud.net> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* OMAP3: igep00x0: Fix boot hang and add support for status LED.Enric Balletbo i Serra2015-01-29-4/+14
| | | | | | | | | | | | Use the STATUS_LED APIs for indicating a boot progress instead of show_boot_progress. This patch also fixes a problem introduced with commit b3f4ca1135 (dm: omap3: Move to driver model for GPIO and serial). After that commit the board doesn't boot. Looks like the problem is the gpio_request call inside the function show_boot_progress. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* ARM: TI: omap3: remove raw initrd support in omap3_igep00x0 config file ↵Guillaume GARDET2014-11-06-2/+0
| | | | | | | | since it is now in ti_armv7_common.h Signed-off-by: Guillaume GARDET <guillaume.gardet@free.fr> Cc: Tom Rini <trini@ti.com> Reviewed-by: Tom Rini <trini@ti.com>
* ARM: omap: move board specific NAND configs out from ti_armv7_common.hpekon gupta2014-07-25-0/+7
| | | | | | | | | | | | | | | | | This patch moves some board specific NAND configs: - FROM: generic config file 'ti_armv7_common.h' - TO: individual board config files using these configs. So that each board can independently set the value as per its design. Following configs are affected in this patch: CONFIG_SYS_NAND_U_BOOT_OFFS: <refer doc/README.nand> CONFIG_CMD_SPL_NAND_OFS: <refer doc/README.falcon> CONFIG_SYS_NAND_SPL_KERNEL_OFFS: <refer doc/README.falcon> CONFIG_CMD_SPL_WRITE_SIZE: <refer doc/README.falcon> This patch also updates documentation for few of above NAND configs. Signed-off-by: Pekon Gupta <pekon@ti.com>
* ARM: omap: clean redundant PISMO_xx macros used in OMAP3pekon gupta2014-07-25-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PISMO_xx macros were used to define 'Platform Independent Storage MOdule' related GPMC configurations. This patch - Replaces these OMAP3 specific macros with generic CONFIG_xx macros as provided by current u-boot infrastructure. - Removes unused redundant macros, which are no longer required after merging of common platform code in following commit commit a0a37183bd75e74608bc78c8d0e2a34454f95a91 ARM: omap: merge GPMC initialization code for all platform +-----------------+-----------------------------------------------------------+ | Macro | Reason for removal | +-----------------+-----------------------------------------------------------+ | PISMO1_NOR_BASE | duplicate of CONFIG_SYS_FLASH_BASE | +-----------------+-----------------------------------------------------------+ | PISMO1_NAND_BASE| duplicate of CONFIG_SYS_NAND_BASE | +-----------------+-----------------------------------------------------------+ | PISMO1_ONEN_BASE| duplicate of CONFIG_SYS_ONENAND_BASE | +-----------------+-----------------------------------------------------------+ | PISMO1_NAND_SIZE| GPMC accesses NAND device via I/O mapped registers so | | | configuring GPMC chip-select for smallest allowable | | | segment (GPMC_SIZE_16M) is enough. | +-----------------+-----------------------------------------------------------+ | PISMO1_ONEN_SIZE| OneNAND uses a fixed GPMC chip-select address-space of | | | 128MB (GPMC_SIZE_128M) | +-----------------+-----------------------------------------------------------+ +-----------------+-----------------------------------------------------------+ | PISMO1_NOR | Unused Macros | | PISMO1_NAND | | | PISMO2_CS0 | | | PISMO2_CS1 | | | PISMO1_ONENAND | | | PISMO2_NAND_CS0 | | | PISMO2_NAND_CS1 | | | PISMO1_NOR_BASE | | | PISMO1_NAND_BASE| | | PISMO2_CS0_BASE | | +-----------------+-----------------------------------------------------------+ Signed-off-by: Pekon Gupta <pekon@ti.com>
* mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device ↵pekon gupta2014-06-06-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>
* Merge branch 'master' of git://git.denx.de/u-boot-armTom Rini2014-03-10-0/+5
|\
| * 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>
* | mtd: nand: omap: remove unused #defines from common omap_gpmc.hpekon gupta2014-03-04-1/+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>
* OMAP3: igep00x0: Convert to ti_omap3_common.h.Enric Balletbò i Serra2014-01-24-180/+9
| | | | | | To reduce code duplication update omap3_igep00x0.h to use ti_omap3_common.h. Signed-off-by: Enric Balletbo i Serra <eballetbo@gmail.com>
* Merge branch 'master' of git://git.denx.de/u-boot-nand-flashTom Rini2013-11-25-0/+1
|\
| * mtd: nand: omap: add CONFIG_NAND_OMAP_ECCSCHEME for selection of ecc-schemepekon gupta2013-11-21-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds new CONFIG_NAND_OMAP_ECCSCHEME, replacing other distributed CONFIG_xx used for selecting NAND ecc-schemes. This patch aims at solving following issues. 1) Currently ecc-scheme is tied to SoC platform, which prevents user to select other ecc-schemes also supported in hardware. like; - most of OMAP3 SoC platforms use only 1-bit Hamming ecc-scheme, inspite the fact that they can use higher ecc-schemes like 8-bit ecc-schemes with software based error detection (OMAP_ECC_BCH4_CODE_HW_DETECTION_SW). - most of AM33xx SoC plaforms use 8-bit BCH ecc-scheme for now, but hardware supports BCH16 ecc-scheme also. 2) Different platforms use different CONFIG_xx to select ecc-schemes, which adds confusion for user while migrating platforms. - *CONFIG_NAND_OMAP_ELM* which enables ELM hardware engine, selects only 8-bit BCH ecc-scheme with h/w based error-correction (OMAP_ECC_BCH8_CODE_HW) whereas ELM hardware engine supports other ecc-schemes also like; BCH4, and BCH16 (in future). - *CONFIG_NAND_OMAP_BCH8* selects 8-bit BCH ecc-scheme with s/w based error correction (OMAP_ECC_BCH8_CODE_HW_DETECTION_SW). - *CONFIG_SPL_NAND_SOFTECC* selects 1-bit Hamming ecc-scheme using s/w library Thus adding new *CONFIG_NAND_OMAP_ECCSCHEME* de-couples ecc-scheme dependency on SoC platform and NAND driver. And user can select ecc-scheme independently foreach board. However, selection some hardware based ecc-schemes (OMAP_ECC_BCHx_CODE_HW) still depends on presence of ELM hardware engine on SoC. (Refer doc/README.nand) Signed-off-by: Pekon Gupta <pekon@ti.com>
* | i2c, omap24xx: convert driver to new mutlibus/mutliadapter frameworkHeiko Schocher2013-11-13-4/+4
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - add omap24xx driver to new multibus/multiadpater support - adapted all config files, which uses this driver Tested on the am335x based siemens boards rut, dxr2 and pxm2 posted here: http://patchwork.ozlabs.org/patch/263211/ Signed-off-by: Heiko Schocher <hs@denx.de> Tested-by: Tom Rini <trini@ti.com> Cc: Lars Poeschel <poeschel@lemonage.de> Cc: Steve Sakoman <sakoman@gmail.com> Cc: Thomas Weber <weber@corscience.de> Cc: Tom Rix <Tom.Rix@windriver.com> Cc: Grazvydas Ignotas <notasas@gmail.com> Cc: Enric Balletbo i Serra <eballetbo@iseebcn.com> Cc: Luca Ceresoli <luca.ceresoli@comelit.it> Cc: Igor Grinberg <grinberg@compulab.co.il> Cc: Ilya Yanok <yanok@emcraft.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Nishanth Menon <nm@ti.com> Cc: Pali Rohár <pali.rohar@gmail.com> Cc: Peter Barada <peter.barada@logicpd.com> Cc: Nagendra T S <nagendra@mistralsolutions.com> Cc: Michael Jones <michael.jones@matrix-vision.de> Cc: Raphael Assenat <raph@8d.com> Acked-by: Igor Grinberg <grinberg@compulab.co.il> Acked-by: Stefano Babic <sbabic@denx.de>
* Merge branch 'iu-boot/master' into 'u-boot-arm/master'Albert ARIBAUD2013-11-09-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: arch/arm/cpu/arm926ejs/mxs/Makefile board/compulab/cm_t35/Makefile board/corscience/tricorder/Makefile board/ppcag/bg0900/Makefile drivers/bootcount/Makefile include/configs/omap4_common.h include/configs/pdnb3.h Makefile conflicts are due to additions/removals of object files on the ARM branch vs KBuild introduction on the main branch. Resolution consists in adjusting the list of object files in the main branch version. This also applies to two files which are not listed as conflicting but had to be modified: board/compulab/common/Makefile board/udoo/Makefile include/configs/omap4_common.h conflicts are due to the OMAP4 conversion to ti_armv7_common.h on the ARM side, and CONFIG_SYS_HZ removal on the main side. Resolution is to convert as this icludes removal of CONFIG_SYS_HZ. include/configs/pdnb3.h is due to a removal on ARM side. Trivial resolution is to remove the file. Note: 'git show' will also list two files just because they are new: include/configs/am335x_igep0033.h include/configs/omap3_igep00x0.h
* OMAP3: igep00x0: rename config file to omap3_igep00x0.hJavier Martinez Canillas2013-11-01-0/+370
There seems to be a naming convention for the configuration files for boards using the same SoC family. This makes easier to do changes that affect different boards based on the same SoC. Since the IGEPv2 board and the IGEP COM Module use a TI OMAP35xx/DM37xx processor, is better to rename its board config to use this naming scheme. Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Acked-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>