summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2014-07-07fit: make sha256 support optionalDirk Eibach
sha256 has some beefy memory footprint. Make it optional for constrained systems. Signed-off-by: Dirk Eibach <dirk.eibach@gdsys.cc>
2014-07-07board: gdsys: Remove commands to reduce footprintDirk Eibach
Commit "2842c1c fit: add sha256 support" badly increased memory footprint, so some of our boards did not build anymore. Since monitor base must not be changed I removed some commands to save memory. Maybe making sha256 optional for fit would be an option for the future since it really has some beefy footprint. Signed-off-by: Dirk Eibach <dirk.eibach@gdsys.cc>
2014-07-07board: gdsys: Make gdsys osd hardware detection more robustDirk Eibach
Signed-off-by: Dirk Eibach <dirk.eibach@gdsys.cc>
2014-07-07board: gdsys: Configure bridge on DP501 to support DDC onlyDirk Eibach
The I2C bridge on DP501 supports EDID, MCCS and HDCP by default. Allow EDID only to avoid I2C address conflicts. Signed-off-by: Dirk Eibach <dirk.eibach@gdsys.cc>
2014-07-07board: gdsys: Increase iocon and dlv10g version stringDirk Eibach
Signed-off-by: Dirk Eibach <dirk.eibach@gdsys.cc>
2014-07-07board: gdsys: Fix dlvision-10g I2C configurationDirk Eibach
PPC4xx config options were not complete. ICS8N3QV01 and SIL1178 needed some more configuration. Signed-off-by: Dirk Eibach <dirk.eibach@gdsys.cc>
2014-07-07i2c: IHS I2C master driverDirk Eibach
IHS I2C master support was merely a hack in the osd driver. Now it is a proper u-boot I2C framework driver, supporting the v2.00 master features. Signed-off-by: Dirk Eibach <dirk.eibach@gdsys.cc>
2014-07-07board: iocon: Support DisplayPort hardwareDirk Eibach
There is a new iocon hardware flavor, supporting DisplayPort finally. Signed-off-by: Dirk Eibach <dirk.eibach@gdsys.cc>
2014-07-07mpc8xx: remove spc1920 board supportMasahiro Yamada
This board is old enough and has no maintainer. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-07-07mpc8xx: remove v37 board supportMasahiro Yamada
This board is old enough and has no maintainer. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-07-07mpc8xx: remove fads board supportMasahiro Yamada
These boards are old enough and have no maintainers. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-07-07mpc8xx: remove netta, netta2, netphone board supportMasahiro Yamada
These boards are old enough and have no maintainers. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-07-07mpc8xx: remove rbc823 board supportMasahiro Yamada
This board is old enough and has no maintainer. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-07-07mpc8xx: remove RPXlite_dw, quantum board supportMasahiro Yamada
These boards are old enough and have no maintainers. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-07-07mpc8xx: remove qs850, qs860t board supportMasahiro Yamada
These boards are old enough and have no maintainers. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-07-07env_fat: use get_device_and_partition() during env save and loadWu, Josh
Use get_device_and_partition() is better since: 1. It will call the device initialize function internally. So we can remove the mmc intialization code to save many lines. 2. It is used by fatls/fatload/fatwrite. So saveenv & load env should use it too. 3. It can parse the "D:P", "D", "D:", "D:auto" string to get correct device and partition information by run-time. Also we remove the FAT_ENV_DEVICE and FAT_ENV_PART. We use a string: FAT_ENV_DEVICE_AND_PART. For at91sam9m10g45ek, it is "0". That means use device 0 and if: a)device 0 has no partition table, use the whole device as a FAT file system. b)device 0 has partittion table, use the partition #1. Refer to the commit: 10a37fd7a4 for details of device & partition string. Signed-off-by: Josh Wu <josh.wu@atmel.com> Reviewed-by: Stephen Warren <swarren@nvidia.com>
2014-07-05integrator: switch to generic boardLinus Walleij
Turn on generic board for the integrators, as per the request in the startup message. Everything just works, tested on the Integrator/AP and Integrator/CP. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Simon Glass <sjg@chromium.org>
2014-07-05ARM: rpi_b: enable GENERIC_BOARDStephen Warren
Serial port, SD card, and LCD all work. Signed-off-by: Stephen Warren <swarren@wwwdotorg.org> Acked-by: Simon Glass <sjg@chromium.org>
2014-07-05arm, calimain: Add CONFIG_SYS_GENERIC_BOARDChristian Riesch
Signed-off-by: Christian Riesch <christian.riesch@omicron.at>
2014-07-05arm:board:h2200: Add CONFIG_SYS_GENERIC_BOARDŁukasz Dałek
Enable 'generic board init' for H2200 palmtop. Signed-off-by: Lukasz Dalek <luk0104@gmail.com> Acked-by: Marek Vasut <marex@denx.de>
2014-07-04socfpga: Adding Scan Manager driverChin Liang See
Scan Manager driver will be called to configure the IOCSR scan chain. This configuration will setup the IO buffer settings Signed-off-by: Chin Liang See <clsee@altera.com> Cc: Dinh Nguyen <dinguyen@altera.com> Cc: Wolfgang Denk <wd@denx.de> CC: Pavel Machek <pavel@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
2014-07-04socfpga: Adding DesignWare watchdog supportChin Liang See
To enable the DesignWare watchdog support at SOCFPGA Cyclone V dev kit. Signed-off-by: Chin Liang See <clsee@altera.com> Cc: Anatolij Gustschin <agust@denx.de> Cc: Albert Aribaud <albert.u.boot@aribaud.net> Cc: Heiko Schocher <hs@denx.de> Cc: Tom Rini <trini@ti.com>
2014-07-04arm: ep9315: Return back Cirrus Logic EDB9315A board supportSergey Kostanbaev
This patch returns back support for old ep93xx processors family Signed-off-by: Sergey Kostanbaev <sergey.kostanbaev@gmail.com> Cc: albert.u.boot@aribaud.net
2014-07-04ARMv8/ls2085a_emu: Add LS2085A emulator and simulator board supportYork Sun
LS2085A is an ARMv8 implementation. This adds board support for emulator and simulator: Two DDR controllers UART2 is used as the console IFC timing is tightened for speedy booting Support DDR3 and DDR4 as separated targets Management Complex (MC) is enabled Support for GIC 500 (based on GICv3 arch) Signed-off-by: York Sun <yorksun@freescale.com> Signed-off-by: Arnab Basu <arnab.basu@freescale.com> Signed-off-by: J. German Rivera <German.Rivera@freescale.com> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
2014-07-03armv8/fsl-lsch3: Add support to load and start MC FirmwareJ. German Rivera
Adding support to load and start the Layerscape Management Complex (MC) firmware. First, the MC GCR register is set to 0 to reset all cores. MC firmware and DPL images are copied from their location in NOR flash to DDR. MC registers are updated with the location of these images. Deasserting the reset bit of MC GCR register releases core 0 to run. Core 1 will be released by MC firmware. Stop bits are not touched for this step. U-boot waits for MC until it boots up. In case of a failure, device tree is updated accordingly. The MC firmware image uses FIT format. Signed-off-by: J. German Rivera <German.Rivera@freescale.com> Signed-off-by: York Sun <yorksun@freescale.com> Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com> Signed-off-by: Shruti Kanetkar <Shruti@Freescale.com>
2014-07-03ARMv8/FSL_LSCH3: Add FSL_LSCH3 SoCYork Sun
Freescale LayerScape with Chassis Generation 3 is a set of SoCs with ARMv8 cores and 3rd generation of Chassis. We use different MMU setup to support memory map and cache attribute for these SoCs. MMU and cache are enabled very early to bootst performance, especially for early development on emulators. After u-boot relocates to DDR, a new MMU table with QBMan cache access is created in DDR. SMMU pagesize is set in SMMU_sACR register. Both DDR3 and DDR4 are supported. Signed-off-by: York Sun <yorksun@freescale.com> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com> Signed-off-by: Arnab Basu <arnab.basu@freescale.com>
2014-07-03arm: Add support for semihosting for armv8 fastmodel targets.Darwin Rambo
The armv8 ARM Trusted Firmware (ATF) can be used to load various ATF images and u-boot, and does this for virtual platforms by using semihosting. This commit extends this idea by allowing u-boot to also use semihosting to load the kernel/ramdisk/dtb. This eliminates the need for a bootwrapper and produces a more realistic boot sequence with virtual models. Though the semihosting code is quite generic, support for armv7 in fastmodel is less useful due to the wide range of available silicon and the lack of a free armv7 fastmodel, so this change contains an untested armv7 placeholder for the service trap opcode. Please refer to doc/README.semihosting for a more detailed description of semihosting and how it is used with the armv8 virtual platforms. Signed-off-by: Darwin Rambo <drambo@broadcom.com> Cc: trini@ti.com Cc: fenghua@phytium.com.cn Cc: bhupesh.sharma@freescale.com
2014-07-01Merge remote-tracking branch 'u-boot-samsung/master'Albert ARIBAUD
Conflicts: boards.cfg Conflict was trivial between goni maintainer change and lager_nor removal.
2014-07-01Merge branch 'u-boot-tegra/master' into 'u-boot-arm/master'Albert ARIBAUD
2014-07-01Merge branch 'u-boot-ti/master' into 'u-boot-arm/master'Albert ARIBAUD
2014-06-30Merge branch 'u-boot-imx/master' into 'u-boot-arm/master'Albert ARIBAUD
2014-06-26mx25pdk: Remove CONFIG_SYS_GENERIC_BOARDFabio Estevam
With CONFIG_SYS_GENERIC_BOARD the board hangs after issuing a 'save' command. Remove CONFIG_SYS_GENERIC_BOARD until this issue can be fixed properly. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
2014-06-25Merge branch 'u-boot/master' into 'u-boot-arm/master'Albert ARIBAUD
2014-06-24Merge branch 'master' of git://git.denx.de/u-boot-dmTom Rini
2014-06-24Merge branch 'u-boot-atmel/master' into 'u-boot-arm/master'Albert ARIBAUD
2014-06-23mpc8313: add CONFIG_SYS_GENERIC_BOARD to ids8313 boardHeiko Schocher
- add CONFIG_SYS_GENERIC_BOARD - remove CONFIG_OF_CONTROL to boot again Signed-off-by: Heiko Schocher <hs@denx.de> Acked-by: Kim Phillips <kim.phillips@freescale.com> Acked-by: Simon Glass <sjg@chromium.org>
2014-06-22Exynos: Split 5250 and 5420 memory bank configurationMichael Pratt
Since snow has a different memory configuration than peach, split the configuration between the 5250 and 5420. Exynos 5420 supports runtime memory configuration detection, and can make the determination between 4 and 7 banks at runtime. Include the bank size with the number of banks for context to make the number of banks meaningful. Signed-off-by: Michael Pratt <mpratt@chromium.org> Signed-off-by: Akshay Saraswat <akshay.s@samsung.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
2014-06-22Exynos5: Config: Enable USB boot mode for all Exynos5 SoCsAkshay Saraswat
Right now USB booting is enabled for Exynos5250 only. Moving all the configs for USB boot mode from exynos5250-dt.h to exynos5-dt.h in order to enableUSB booting for all Exynos5 SoCs. Signed-off-by: Akshay Saraswat <akshay.s@samsung.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
2014-06-22Exynos5: Config: Increase SPL footprint for Exynos5420Akshay Saraswat
Max footprint for SPL in both Exynos 5250 and 5420 is limited to 14 KB. For Exynos5250 we need to keep it 14 KB because BL1 supports only fixed size SPL downloading. But in case of Exynos5420 we need not restrict it to 14 KB. And also, the SPL size for Exynos5420 is expected to increase with the upcoming patches and the patches under review right now. Signed-off-by: Akshay Saraswat <akshay.s@samsung.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
2014-06-22Exynos5: Config: Place environment at the end of SPI flashAkshay Saraswat
Currently environment resides at the location where BL2 ends. This may hold good in case there is an empty space at this position. But what if this place already has a binary or is expected to have one. To avoid such scenarios it is better to save environment at the end of the flash. Signed-off-by: Akshay Saraswat <akshay.s@samsung.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
2014-06-22Exynos5420: Introduce support for the Peach-Pit boardAkshay Saraswat
While the Exynos5420 chip is used in both Smdk5420 and in the Peach-Pit line of devices, there could be other boards using the same chip, so a common configuration file is being added (exynos5420.h) as well as two common device tree files (exynos54xx.dtsi & exynos5420.dtsi). The peach board as declared in boards.cfg is a copy of smdk5420 declaration. The configuration files are similar, but define different default device trees, console serial ports and prompts. The device tree files for smdk5420 and peach-pit inherit from the same common file. Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Signed-off-by: Akshay Saraswat <akshay.s@samsung.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
2014-06-21include/dm.h: fix inclusion guardJeroen Hofstee
cc: Simon Glass <sjg@chromium.org> Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl> Acked-by: Simon Glass <sjg@chromium.org>
2014-06-20dm: Tidy up four minor code nitsSimon Glass
There is a spelling mistake and two functions are missing comments altogether. Also the flags declaration is correct, but doesn't follow style. Finally, the uclass_get_device() function has some errors in its documentation. Fix these problems. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Marek Vasut <marex@denx.de>
2014-06-20tegra: Enable driver modelSimon Glass
Enable driver model for Tegra boards. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Stephen Warren <swarren@nvidia.com>
2014-06-20tegra: dts: Bring in GPIO bindings from linuxSimon Glass
These files are taken from Linux 3.14. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Stephen Warren <swarren@nvidia.com>
2014-06-20dm: Cast away the const-ness of the global_data pointerSimon Glass
In a very few cases we need to adjust the driver model root device, such as when setting it up at initialisation. Add a macro to make this easier. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-06-20dm: Rename struct device_id to udevice_idSimon Glass
It is best to avoid having any occurence of 'struct device' in driver model, so rename to achieve this. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-06-20sandbox: Support iotrace featureSimon Glass
Support the iotrace feature for sandbox, and enable it, using some dummy I/O access methods. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-06-20Add an I/O tracing featureSimon Glass
When debugging drivers it is useful to see what I/O accesses were done and in what order. Even if the individual accesses are of little interest it can be useful to verify that the access pattern is consistent each time an operation is performed. In this case a checksum can be used to characterise the operation of a driver. The checksum can be compared across different runs of the operation to verify that the driver is working properly. In particular, when performing major refactoring of the driver, where the access pattern should not change, the checksum provides assurance that the refactoring work has not broken the driver. Add an I/O tracing feature and associated commands to provide this facility. It works by sneaking into the io.h heder for an architecture and redirecting I/O accesses through its tracing mechanism. For now no commands are provided to examine the trace buffer. The format is fairly simple, so 'md' is a reasonable substitute. Note: The checksum feature is only useful for I/O regions where the contents do not change outside of software control. Where this is not suitable you can fall back to manually comparing the addresses. It might be useful to enhance tracing to only checksum the accesses and not the data read/written. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-06-19omap3: overo: Select fdtfile for expansion boardAsh Charles
The u-boot Overo board actually supports both Overo (OMAP35xx) and Overo Storm (AM/DM37xx) COMs with a range of different expansion boards. This provides a mechanism to select the an appropriate device tree file based on the processor version and, if available, the expansion board ID written on the expansion board EEPROM. To match the 3.15+ kernels, fdtfile names have this format: "omap3-overo[-storm]-<expansion board name>.dtb" By default, we use "omap3-overo-storm-tobi.dtb". Signed-off-by: Ash Charles <ashcharles@gmail.com> Conflicts: include/configs/omap3_overo.h