summaryrefslogtreecommitdiff
path: root/include/configs/am57xx_evm.h
Commit message (Collapse)AuthorAgeLines
* Convert CONFIG_SPL_DMA_SUPPORT to KconfigSimon Glass2016-09-16-1/+0
| | | | | | Move this option to Kconfig and tidy up existing uses. Signed-off-by: Simon Glass <sjg@chromium.org>
* configs: Migrate CONFIG_USB_STORAGETom Rini2016-09-09-1/+0
| | | | | | | In some cases we were missing CONFIG_USB=y so enable that when needed. Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Tom Rini <trini@konsulko.com>
* TI: Rework SRAM definitions and maximumsTom Rini2016-09-06-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On all TI platforms the ROM defines a "downloaded image" area at or near the start of SRAM which is followed by a reserved area. As it is at best bad form and at worst possibly harmful in corner cases to write in this reserved area, we stop doing that by adding in the define NON_SECURE_SRAM_IMG_END to say where the end of the downloaded image area is and make SRAM_SCRATCH_SPACE_ADDR be one kilobyte before this. At current we define the end of scratch space at 0x228 bytes past the start of scratch space this this gives us a lot of room to grow. As these scratch uses are non-optional today, all targets are modified to respect this boundary. Tested on OMAP4 Pandaboard, OMAP3 Beagle xM Cc: Albert Aribaud <albert.u.boot@aribaud.net> Cc: Nagendra T S <nagendra@mistralsolutions.com> Cc: Vaibhav Hiremath <hvaibhav@ti.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Igor Grinberg <grinberg@compulab.co.il> Cc: Nikita Kiryanov <nikita@compulab.co.il> Cc: Paul Kocialkowski <contact@paulk.fr> Cc: Enric Balletbo i Serra <eballetbo@gmail.com> Cc: Adam Ford <aford173@gmail.com> Cc: Steve Sakoman <sakoman@gmail.com> Cc: Stefan Roese <sr@denx.de> Cc: Thomas Weber <weber@corscience.de> Cc: Hannes Schmelzer <oe5hpm@oevsv.at> Cc: Thomas Chou <thomas@wytron.com.tw> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Simon Glass <sjg@chromium.org> Cc: Joe Hershberger <joe.hershberger@ni.com> Cc: Sam Protsenko <semen.protsenko@linaro.org> Cc: Heiko Schocher <hs@denx.de> Cc: Samuel Egli <samuel.egli@siemens.com> Cc: Michal Simek <michal.simek@xilinx.com> Cc: Wolfgang Denk <wd@denx.de> Cc: Mateusz Kulikowski <mateusz.kulikowski@gmail.com> Cc: Ben Whitten <ben.whitten@gmail.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Bin Meng <bmeng.cn@gmail.com> Cc: Sekhar Nori <nsekhar@ti.com> Cc: Mugunthan V N <mugunthanvnm@ti.com> Cc: "B, Ravi" <ravibabu@ti.com> Cc: "Matwey V. Kornilov" <matwey.kornilov@gmail.com> Cc: Ladislav Michl <ladis@linux-mips.org> Cc: Ash Charles <ashcharles@gmail.com> Cc: "Kipisz, Steven" <s-kipisz2@ti.com> Cc: Daniel Allred <d-allred@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com> Tested-by: Lokesh Vutla <lokeshvutla@ti.com> Acked-by: Lokesh Vutla <lokeshvutla@ti.com> Tested-by: Ladislav Michl <ladis@linux-mips.org>
* usb: add (move) CONFIG_USB_HOST to KconfigMasahiro Yamada2016-08-07-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | The meaning of CONFIG_USB in U-Boot is different from that in Linux. As you see in drivers/usb/Kconfig of Linux, CONFIG_USB enables the USB host controller support, while CONFIG_USB_SUPPORT is used to enable the whole of the USB sub-system. When I added CONFIG_USB into Kconfig by commit 6e7e9294d321 ("usb: add basic USB configs in Kconfig"), I planned to follow the Linux's convention, i.e. CONFIG_USB to enable/disable the USB host support. Then, commit 68f7c5db2d1e ("usb: Generic USB Kconfig option, that fits both host and gadget and comments") changed the logic of the CONFIG_USB to point to the whole of the USB sub-system. As a result, currently we do not have an option for USB host. This commit adds CONFIG_USB_HOST, which will be useful to compile in the USB host support code. CONFIG_USB_HOST is not referenced at all, but strangely some boards define it in board headers. I removed them because USB_HOST will be selected in Kconfig going forward. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: am57xx_evm: Enable QSPI supportVignesh R2016-07-30-0/+36
| | | | | | | | | | AM571x IDK and AM572x IDK EVMs have spansion s25fl256s QSPI flash on the board connected to TI QSPI IP over CS0. Therefore enable QSPI support. Signed-off-by: Vignesh R <vigneshr@ti.com> Reviewed-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Jagan Teki <jteki@openedev.com>
* usb: move CONFIG_USB_XHCI_DWC3 to KconfigMasahiro Yamada2016-06-04-1/+0
| | | | | | | Create an entry for "config USB_XHCI_DWC3" in Kconfig and switch over to it for all boards. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* usb: move CONFIG_USB_XHCI to Kconfig with renamingMasahiro Yamada2016-06-04-1/+0
| | | | | | | | | | | | | | | | | Move CONFIG_USB_XHCI to defconfig files for all boards, renaming it into CONFIG_USB_XHCI_HCD. As commented in the help of "config USB_XHCI" entry, this has been a TODO for a long time; now CONFIG_USB_XHCI_HCD and CONFIG_USB_XHCI have been unified in favor of the former. Note: Some boards define CONFIG_USB_XHCI in their headers without CONFIG_USB, which does not meet the "depends on" in Kconfig. I added CONFIG_USB=y for those boards when converting. Otherwise, they would fail to build. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* dm: scsi: Rename CONFIG_CMD_SCSI to CONFIG_SCSISimon Glass2016-05-17-1/+1
| | | | | | | | This option currently enables both the command and the SCSI functionality. Rename the existing option to CONFIG_SCSI since most of the code relates to the feature. Signed-off-by: Simon Glass <sjg@chromium.org>
* configs: Re-sync with cmd/KconfigTom Rini2016-04-25-1/+0
| | | | | | | Update the config.h and defconfig files for the commands that 8e3c036 converted over to Kconfig Signed-off-by: Tom Rini <trini@konsulko.com>
* configs: Re-sync almost all of cmd/KconfigTom Rini2016-04-25-3/+0
| | | | | | | | This syncs up the current cmd/Kconfig and include/configs/ files with the only exception being CMD_NAND. Due to how we have used this historically we need to take further care here when converting. Signed-off-by: Tom Rini <trini@konsulko.com>
* board: ti: AM57xx: Add detection logic for AM57xx-evmKipisz, Steven2016-03-14-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current AM57xx evm supports both BeagleBoard-X15 (http://beagleboard.org/x15) and AM57xx EVM (http://www.ti.com/tool/tmdxevm5728). The AM572x EValuation Module(EVM) provides an affordable platform to quickly start evaluation of Sitara. ARM Cortex-A15 AM57x Processors (AM5728, AM5726, AM5718, AM5716) and accelerate development for HMI, machine vision, networking, medical imaging and many other industrial applications. This EVM is based on the same BeagleBoard-X15 Chassis and adds mPCIe, mSATA, LCD, touchscreen, Camera, push button and TI's wlink8 offering. Since the EEPROM contents are compatible between the BeagleBoard-X15 and the AM57xx-evm, we add support for the detection logic to enable support for various user programmable scripting capability. NOTE: U-boot configuration is currently a superset of AM57xx evm and BeagleBoard-X15 and no additional configuration tweaking is needed. This change also sets up the stage for future support of TI AM57xx EVMs to the same base bootloader build. Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* board: ti: beagle_x15: Rename to indicate support for TI am57xx evmsKipisz, Steven2015-11-18-0/+91
BeagleBoard X15 (http://beagleboard.org/x15) support in u-boot does actually support two different platform configuration offered by TI. In addition to BeagleBoard X15, it also supports the TMDXEVM5728 (or more commonly known as AM5728-evm). Information about the TI AM57xx EVM can be found here http://www.ti.com/tool/tmdxevm5728 The EVM configuration is 1-1 compatible with BeagleBoard X15 with the additional support for mPCIe, mSATA, LCD, touchscreen, Camera, push button and TI's wlink8 offering. Hence, we rename the beagle_x15 directory to am57xx to support TI EVMs that use the AM57xx processor. By doing this we have common code reuse. This sets the stage to have a common u-boot image solution for multiple TI EVMs such as that already done for am335x and am437x. This sets the stage for upcoming multiple TI EVMs that share the same code base. NOTE: Commit eae7ae185335 ("am437x: Add am57xx_evm_defconfig using CONFIG_DM") introduced DT support for beagle_x15 under am57xx_evm platform name. However, this ignored the potential confusion arising for users as a result. To prevent this, existing beagle_x15_defconfig is renamed as am57xx_evm_nodt_defconfig to denote that this is the "non device tree" configuration for the same platform. We still retain am57xx-beagle-x15.dts at this point, since we just require the common minimum dts. As a result of this change, users should expect changes in build procedures('make am57xx_evm_nodt_defconfig' instead of 'make beagle_x15_defconfig'). Hopefully, this would be a one-time change. Signed-off-by: Steve Kipisz <s-kipisz2@ti.com> Signed-off-by: Schuyler Patton <spatton@ti.com> Acked-by: Nishanth Menon <nm@ti.com> Acked-by: Lokesh Vutla <lokeshvutla@ti.com>