The main loop is easier to follow if the code is grouped into separate
functions. Make this change, so that main_loop() is easier to read.
Signed-off-by: Simon Glass <sjg@chromium.org>
This code seems unnecessarily complex. We really just need to check the
global_data. Now that is it all in one place, and not arch-specific, this
is pretty easy.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a bootretry_ prefix to these two functions, and remove the need for
the #ifdef around everything (it moves to the Makefile).
Signed-off-by: Simon Glass <sjg@chromium.org>
This code is only used by one board, so it seems a shame to clutter up
the readline code with it. Move it into its own file.
Signed-off-by: Simon Glass <sjg@chromium.org>
It doesn't make sense to have the simple parser and the readline code
all in main. Split them out into separate files.
Signed-off-by: Simon Glass <sjg@chromium.org>
Development board for headless gateway platform from Abilis Systems.
Initial commit with working UART and DW GMAC.
For now with generic Ethernet PHY due to problems in Realtek PHY driver.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Christian Ruppert <christian.ruppert@abilis.com>
Cc: Pierrick Hascoet <pierrick.hascoet@abilis.com>
using UBI and DM together leads in compiler error, as
both define a "struct device", so rename "struct device"
in include/dm/device.h to "struct udevice", as we use
linux code (MTD/UBI/UBIFS some USB code,...) and cannot
change the linux "struct device"
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Marek Vasut <marex@denx.de>
Make the common eeprom library available for any I2C driver.
Signed-off-by: Ilya Ledvich <ilya@compulab.co.il>
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
cm-t54 Eth MAC address is stored in onboard EEPROM.
Add EEPROM support and setup stored Eth MAC address.
If EEPROM does not contain a valid MAC, then generate it from the
processor ID code (reference code is taken from OMAP5 uEvm board file).
Modify Device Tree blob MAC address field with retrieved data.
Signed-off-by: Dmitry Lifshitz <lifshitz@compulab.co.il>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
As revision code 1 is for silicon revision 2.0, it is easily confused with
silicon revision 1.0.
Device type report also reworked in same style.
Signed-off-by: Sergey Alyoshin <alyoshin.s@gmail.com>
Last section of DMM is used for trapping tiler unmapped sections.
Corresponding trap_size should be deducted from total SDRAM size
only if trap section is overlapping with available SDRAM
based on DMM sections. Fixing the same.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Samuel Egli <samuel.egli@siemens.com>
Cc: Roger Meier <r.meier@siemens.com>
Tested-by: Samuel Egli <samuel.egli@siemens.com>
This adds the Gumstix DuoVero machine [1]. This is a OMAP4430-based
computer-on-module (COM aka SOM) that can be mounted on various
expansion boards with different peripherals.
[1] https://store.gumstix.com/index.php/category/43/
Signed-off-by: Ash Charles <ash@gumstix.com>
[trini: Rename gpmc_enable_gpmc_cs_config to gpmc_enable_gpmc_net_config]
Signed-off-by: Tom Rini <trini@ti.com>
The omap_hw_init_context function (and assorted helpers) is the same for
all OMAP-derived parts as when CHSETTINGS are used, that's the same and
our DDR base is also always the same. In order to make this common we
simply need to update the names of the define for DDR address space
which is also common.
Cc: Sricharan R. <r.sricharan@ti.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tom Rini <trini@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
DRA72 has 1GB connected to EMIF1 only. Updating the details.
And also enable WA for BUG0039 only if corresponding EMIF is present.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Tom Rini <trini@ti.com>
TPS65917 is used in DRA722 evm. Update the address offsets accordingly.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Acked-by: Tom Rini <trini@ti.com>
GPMC controller on TI's OMAP SoC is general purpose controller to interface
with different types of external devices like;
- parallel NOR flash
- parallel NAND flash
- OneNand flash
- SDR RAM
- Ethernet Devices like LAN9220
Though GPMC configurations may be different for each platform depending on
clock-frequency and external device interfacing with controller. But
initialization sequence remains common across all platfoms.
Thus this patch merges gpmc_init() scattered in different arch-xx/mem.c
files into single omap-common/mem-common.c
However, actual platforms specific register config values are still sourced
from corresponding platform specific headers like;
AM33xx: arch/arm/include/asm/arch-am33xx/mem.h
OMAP3: arch/arm/include/asm/arch-omap3/mem.h
OMAP4: arch/arm/include/asm/arch-omap4/mem.h
OMAP4: arch/arm/include/asm/arch-omap5/mem.h
Also, CONFIG_xx passed by board-profile decide config for which set of macros
need to be used for initialization
CONFIG_NAND: initialize GPMC for NAND device
CONFIG_NOR: initialize GPMC for NOR device
CONFIG_ONENAND: initialize GPMC for ONENAND device
Signed-off-by: Pekon Gupta <pekon@ti.com>
[trini: define GPMC_SIZE_256M for omap3]
Signed-off-by: Tom Rini <trini@ti.com>
In case of multilib-enabled toolchains if default architecture differ from
the one examples are being built for linker will fail to link example object
files with libgcc of another (non-compatible) architecture.
Interesting enough for years in main Makefile we used CFLAGS/c_flags for this
but not for examples.
So fixing it now.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Tom Rini <trini@ti.com>
Cc: Wolfgang Denx <wd@denx.de>
Acked-by: WOlfgang Denk <wd@denx.de>
Acked-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
This patch moves platform specific information for GPMC and ELM controller
into separate header files, so that any derivative devices do not mess other
header files.
Platform specific information added into arch-xx/../hardware.h
- CPU related platform specific details like base-address of GPMC and ELM
Platform specific information added into arch-xx/../mem.h
- Generic configs for GPMC and ELM initialization.
- Hardware parameters or constrains specific to GPMC and ELM IP like;
number of max number of chip-selects available
Signed-off-by: Pekon Gupta <pekon@ti.com>
This patch moves platform specific information for GPMC and ELM controller
into separate header files, so that any derivative devices do not mess other
header files.
Platform specific information added into arch-xx/../hardware.h
- CPU related platform specific details like base-address of GPMC and ELM
Platform specific information added into arch-xx/../mem.h
- Generic configs for GPMC and ELM initialization.
- Hardware parameters or constrains specific to GPMC and ELM IP like;
number of max number of chip-selects available
Signed-off-by: Pekon Gupta <pekon@ti.com>
Clean-up the board configuration file for the Gumstix Overo board by
including common omap3 definitions from ti_omap3_common.h as suggested
here [1].
[1] http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/185960
Signed-off-by: Ash Charles <ashcharles@gmail.com>
Conflicts:
include/configs/omap3_overo.h
Update the board configuration for Gumstix Overo. In particular,
add support for zImage and DTB files on boot.
Signed-off-by: Ash Charles <ashcharles@gmail.com>
Add EEPROM ID switches for Alto35, Arbor43C, Stagecoach, Thumbo, and
Turtlecore Gumstix Overo expansion boards.
Signed-off-by: Ash Charles <ash@gumstix.com>
Gumstix Overo COMs with board revision 0x4 use a different Wifi and
Bluetooth module: Wi2Wi's W2CBW0015. No other code changes are required
in u-boot---just handling of this particular board revision.
Signed-off-by: Ash Charles <ashcharles@gmail.com>
Patch f33b9bd3
[arm: omap3: Enable clocks for peripherals only if they are used]
breaks SPL booting on Overo. Since some gpio inputs 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: Ash Charles <ashcharles@gmail.com>
The linux kernel is at nand0,3 using the current layout, but is best
accessed through the partition label "linux". Since CONFIG_CMD_MTDPARTS is
defined the CONFIG_JFFS2 settings are unreferenced; use "setenv partition
rootfs" to set the default mtd partition for jffs2.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Tested-by: Ash Charles <ash@gumstix.com>
Linux kernel at version 3.5 is about 3.5 MiB; test kernels for 3.10 exceed 4
MiB. Prepare for future upgrades by increasing the NAND partition now.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Tested-by: Ash Charles <ash@gumstix.com>
The NAND linux partition format default was changed from jffs2 to ubi in
254973e6df but the corresponding commands were
not enabled.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Tested-by: Ash Charles <ash@gumstix.com>
Adapted from d70f5480 described below.
commit d70f54808d
Author: Javier Martinez Canillas <javier@dowhile0.org>
Date: Mon Jan 7 03:51:20 2013 +0000
omap4: allow the use of a plain text env file instead boot scripts
For production systems it is better to use script images since
they are protected by checksums and carry valuable information like
name and timestamp. Also, you can't validate the content passed to
env import.
But for development, it is easier to use the env import command and
plain text files instead of script-images.
Since both OMAP4 supported boards (Panda and TI SDP4430) are used
primarily for development, this patch allows U-Boot to load env var
from a text file in case that an boot.scr script-image is not present.
The variable uenvcmd (if existent) will be executed (using run) after
uEnv.txt was loaded. If uenvcmd doesn't exist the default boot sequence
will be started.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Tested-by: Ash Charles <ash@gumstix.com>
