Current '#if' directives (used in igep00x0.h config file) comparing MACH_TYPE
values in igep00x0.h doesn't work as expected. The comparision between
CONFIG_MACH_TYPE and MACH_TYPE_IGEP0020 is always true independent of the IGEP
machine configured.
For example, following directive
if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020)
define something
endif
Is always evaluated true although we configure u-boot for MACH_TYPE_IGEP0030.
The build doesn't shows any error so looks that both defines had always the same
value. Including the mach-types.h file sets properly the value of
MACH_TYPE_IGEPxxxx.
Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
Ilya Yanok [Tue, 5 Feb 2013 11:36:26 +0000 (11:36 +0000)]
am335x_evm: enable support for booting via USB
This adds necessary config options and a new build target,
am335x_evm_usbspl, to enable usb booting and fixes board_eth_init()
function to take into account that we may have USB ether support in SPL
now. This uses the same MAC for both cpsw and USB, in order to match
ROM behavior.
The usbspl build target does not contain UART SPL, CPSW SPL or extra
environment settings, so that we may fit within our binary size
constraint.
Signed-off-by: Ilya Yanok <ilya.yanok@cogentembedded.com> Signed-off-by: Tom Rini <trini@ti.com>
Ilya Yanok [Tue, 5 Feb 2013 11:36:25 +0000 (11:36 +0000)]
am33xx: support for booting via usbeth
This patch adds BOOT_DEVICE define for USB booting and fixes
spl_board_init function to call arch_misc_init (this is the place there
musb is initialized).
Ilya Yanok [Tue, 5 Feb 2013 11:36:24 +0000 (11:36 +0000)]
spl: support for booting via usbeth
In case of usbeth booting just call net_load_image("usb_ether").
This patch also adds CONFIG_SPL_USBETH_SUPPORT and
CONFIG_SPL_MUSB_NEW_SUPPORT config options to enable linking of SPL
against USB gagdet support and new MUSB driver resp.
Lars Poeschel [Mon, 4 Feb 2013 23:13:58 +0000 (23:13 +0000)]
am33xx: pcm051: Remove wp pin mux for sd-card
The pcm051 does not have the wp pin connected to the sd-card socket.
Therefore remove the pinmux for the pin. The was a carry-over from
the am335x evm code.
Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
Tomas Novotny [Fri, 1 Feb 2013 06:46:00 +0000 (06:46 +0000)]
da8xx: Add the missing pinmux for da830 to the gpio driver
The pinmux was generated from linux/arch/arm/mach-davinci/da830.c as of
kernel version 3.7.5. If the driver is used for the da850, then SoC
variant must be specified by CONFIG_SOC_DA850.
Signed-off-by: Tomas Novotny <tomas@novotny.cz> Cc: Tom Rini <trini@ti.com>
Gabor Juhos [Tue, 12 Feb 2013 21:22:13 +0000 (22:22 +0100)]
MIPS: u-boot.lds: add relocation specific sections
This section contain the table needed for dynamic
relocation. Also provide symbols for the relocation
code to access the table.
Discard all sections which are not needed in the final
ELF binary and U-Boot image. Section .dynsym cannot be
discarded or GNU ld crashes otherwise. This section
will be stripped by GNU objcpy in a later patch.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
MIPS: start.S: use symbol __image_copy_end for U-Boot image relocation
Use the newly introduced symbol __image_copy_end as end address for
relocation of U-Boot image. This is needed for dynamic relocation added
in later patches. This patch obsoletes the symbols uboot_end and
uboot_end_data which are removed.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Get the start and end address for clearing BSS from the newly
introduced symbols __bss_start and __bss_end. After GOT is
relocated, those symbols are already pointing to the correct
addresses.
Also optimize the loop by moving the address incrementation
to the delay slot to avoid the initial sub instruction.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
mips: Move per_clk and dev_clk to arch_global_data
Move these field into arch_global_data and tidy up. The other
CONFIG_JZSOC fields are used by various architectures, so just remove
the #ifdef bracketing for these.
Signed-off-by: Simon Glass <sjg@chromium.org>
commit 582601da2f90b1850aa19f7820b1623c79b3dac6
Author: Simon Glass <sjg@chromium.org>
Date: Thu Dec 13 20:48:35 2012 +0000
arm: Move lastinc to arch_global_data
Move this field into arch_global_data and tidy up.
Signed-off-by: Simon Glass <sjg@chromium.org>
commit 66ee69234795c0596f84b25f06b7fbc2e8ed214c
Author: Simon Glass <sjg@chromium.org>
Date: Thu Dec 13 20:48:34 2012 +0000
arm: Move tbl to arch_global_data
Move this field into arch_global_data and tidy up.
Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Cc: Xiangfu Liu <xiangfu@openmobilefree.net>
Tom Rini [Tue, 12 Feb 2013 19:59:23 +0000 (14:59 -0500)]
am335x_evm: Fix CPSW ethernet on GP EVM and EVM-SK
In commit cfd4ff6 we implemented part of advisory 1.0.10 (internal delay
for RGMII mode not supported). This in turn however requires that we
set the tx clock delay feature in the PHY itself.
Tom Warren [Mon, 28 Jan 2013 13:32:11 +0000 (13:32 +0000)]
Tegra114: Dalmore: Add DT files
These are stripped down for bringup, They'll be filled out later
to match-up with the kernel DT contents, and/or as devices are
brought up (mmc, usb, spi, etc.).
Tom Warren [Mon, 28 Jan 2013 13:32:09 +0000 (13:32 +0000)]
Tegra114: Add CPU (armv7) files
These files are for code that runs on the CPU (A15) on T114 boards.
At this time, there is no A15-specific code here.
As T114-specific run-time code is added, it'll go here.
Tom Warren [Mon, 28 Jan 2013 13:32:07 +0000 (13:32 +0000)]
Tegra114: Add arch-tegra114 include files
Common Tegra files are in arch-tegra, shared between T20/T30/T114.
Tegra114-specific headers are in arch-tegra114. Note that some of
these will be filled in as more T114 support is added (drivers,
WB/LP0 support, etc.).
Signed-off-by: Tom Warren <twarren@nvidia.com> Reviewed-by: Stephen Warren <swarren@nvidia.com>
Allen Martin [Tue, 29 Jan 2013 13:51:28 +0000 (13:51 +0000)]
tegra: add SPI SLINK driver
Add driver for tegra SPI "SLINK" style driver. This controller is
similar to the tegra20 SPI "SFLASH" controller. The difference is
that the SLINK controller is a genernal purpose SPI controller and the
SFLASH controller is special purpose and can only talk to FLASH
devices. In addition there are potentially many instances of an SLINK
controller on tegra and only a single instance of SFLASH. Tegra20 is
currently ths only version of tegra that instantiates an SFLASH
controller.
This driver supports basic PIO mode of operation and is configurable
(CONFIG_OF_CONTROL) to be driven off devicetree bindings. Up to 4
devices per controller may be attached, although typically only a
single chip select line is exposed from tegra per controller so in
reality this is usually limited to 1.
To enable this driver, use CONFIG_TEGRA_SLINK
Signed-off-by: Allen Martin <amartin@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Allen Martin [Tue, 29 Jan 2013 13:51:24 +0000 (13:51 +0000)]
tegra: spi: add fdt support to tegra SPI SFLASH driver
Add support for configuring tegra SPI driver from devicetree.
Support is keyed off CONFIG_OF_CONTROL. Add entry in seaboard dts
file for spi controller to describe seaboard spi.
Signed-off-by: Allen Martin <amartin@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
The libfdt.h file is the definition file for libfdt. It is unnecessary
to include other fdt header files (the necessary ones are pulled in
by libfdt.h).
Signed-off-by: Gerald Van Baren <gvb@unssw.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Stefan Roese <sr@denx.de>
Kim Phillips [Wed, 16 Jan 2013 14:00:11 +0000 (14:00 +0000)]
common/fdt_support.c: sparse fixes
trivial:
fdt_support.c:89:64: warning: Using plain integer as NULL pointer
fdt_support.c:325:65: warning: Using plain integer as NULL pointer
fdt_support.c:352:65: warning: Using plain integer as NULL pointer
For the following bad constant expression, We hardcode the max. number of
memory banks to four for the foreseeable future, and add an error with
instructions on what to do once it's exceeded:
fdt_support.c:397:22: error: bad constant expression
For the rest below, sparse found a couple of wrong endian conversions
in of_bus_default_translate() and fdt_get_base_address(), but
otherwise the rest is mostly annotation fixes:
fdt_support.c:64:24: warning: cast to restricted __be32
fdt_support.c:192:21: warning: incorrect type in assignment (different base types)
fdt_support.c:192:21: expected unsigned int [unsigned] [usertype] tmp
fdt_support.c:192:21: got restricted __be32 [usertype] <noident>
fdt_support.c:201:21: warning: incorrect type in assignment (different base types)
fdt_support.c:201:21: expected unsigned int [unsigned] [addressable] [usertype] tmp
fdt_support.c:201:21: got restricted __be32 [usertype] <noident>
fdt_support.c:304:13: warning: incorrect type in assignment (different base types)
fdt_support.c:304:13: expected unsigned int [unsigned] [usertype] val
fdt_support.c:304:13: got restricted __be32 [usertype] <noident>
fdt_support.c:333:13: warning: incorrect type in assignment (different base types)
fdt_support.c:333:13: expected unsigned int [unsigned] [usertype] val
fdt_support.c:333:13: got restricted __be32 [usertype] <noident>
fdt_support.c:359:13: warning: incorrect type in assignment (different base types)
fdt_support.c:359:13: expected unsigned int [unsigned] [usertype] val
fdt_support.c:359:13: got restricted __be32 [usertype] <noident>
fdt_support.c:373:21: warning: cast to restricted __be32
fdt_support.c:963:48: warning: incorrect type in argument 1 (different base types)
fdt_support.c:963:48: expected restricted __be32 const [usertype] *p
fdt_support.c:963:48: got unsigned int [usertype] *<noident>
fdt_support.c:971:48: warning: incorrect type in argument 1 (different base types)
fdt_support.c:971:48: expected restricted __be32 const [usertype] *p
fdt_support.c:971:48: got unsigned int [usertype] *<noident>
fdt_support.c:984:29: warning: incorrect type in argument 1 (different base types)
fdt_support.c:984:29: expected restricted __be32 const [usertype] *cell
fdt_support.c:984:29: got unsigned int [usertype] *addr
fdt_support.c:996:32: warning: incorrect type in argument 1 (different base types)
fdt_support.c:996:32: expected restricted __be32 const [usertype] *cell
fdt_support.c:996:32: got unsigned int [usertype] *addr
fdt_support.c:1041:41: warning: incorrect type in argument 1 (different base types)
fdt_support.c:1041:41: expected restricted __be32 const [usertype] *cell
fdt_support.c:1041:41: got unsigned int [usertype] *addr
fdt_support.c:1053:41: warning: incorrect type in argument 2 (different base types)
fdt_support.c:1053:41: expected restricted __be32 const [usertype] *range
fdt_support.c:1053:41: got unsigned int const [usertype] *[assigned] ranges
fdt_support.c:1064:53: warning: incorrect type in argument 2 (different base types)
fdt_support.c:1064:53: expected restricted __be32 const [usertype] *addr
fdt_support.c:1064:53: got unsigned int [usertype] *addr
fdt_support.c:1110:50: warning: incorrect type in argument 2 (different base types)
fdt_support.c:1110:50: expected restricted __be32 const [usertype] *addr
fdt_support.c:1110:50: got unsigned int *<noident>
fdt_support.c:1121:49: warning: incorrect type in argument 1 (different base types)
fdt_support.c:1121:49: expected restricted __be32 const [usertype] *cell
fdt_support.c:1121:49: got unsigned int *<noident>
fdt_support.c:1147:60: warning: incorrect type in argument 2 (different base types)
fdt_support.c:1147:60: expected restricted __be32 const [usertype] *addr
fdt_support.c:1147:60: got unsigned int *<noident>
fdt_support.c:1081:5: warning: symbol '__of_translate_address' was not declared. Should it be static?
fdt_support.c:1154:5: error: symbol 'fdt_translate_address' redeclared with different type (originally declared at include/fdt_support.h:95) - incompatible argument 3 (different base types)
fdt_support.c: In function 'fdt_node_offset_by_compat_reg':
fdt_support.c:1173:17: warning: initialization discards 'const' qualifier from pointer target type [enabled by default]
See also linux kernel commit 0131d897 "of/address: use proper
endianess in get_flags".
Signed-off-by: Kim Phillips <kim.phillips@freescale.com> Cc: Jerry Van Baren <gvb.uboot@gmail.com>
Allen Martin [Tue, 8 Jan 2013 16:07:54 +0000 (16:07 +0000)]
fdt: fix dts preprocessor options
Using "-ansi" preprocessor option will cause dts lines that begin with
'#' to choke the preprocessor. Change to "-x assembler-with-cpp"
instead which is what the kernel uses to preprocess dts files.
Signed-off-by: Allen Martin <amartin@nvidia.com> Reviewed-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org>
AM335X: Set fdt_high for AM335X devices to enable booting with Device Tree
For AM335X boards, such as the EVM and Bone Linux kernel fails to
locate the device tree blob on boot. The reason being is that
u-boot is copying the DT blob to the upper part of RAM when booting
the kernel and the kernel is unable to access the blob.
By setting the fdt_high variable to 0xffffffff (to prevent the copy)
the kernel is able to locate the DT blob and boot.
This patch is tested on BeagleBone platform.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Cc: Tom Rini <trini@ti.com>
Jeff Lance [Mon, 14 Jan 2013 05:32:20 +0000 (05:32 +0000)]
Add DDR3 support for AM335x-EVM (Version 1.5A)
AM335x EVM 1.5A uses Micron MT41J512M8RH-125 SDRAM 4Gb (512Mx8) as the
DDR3 chip.
[Hebbar Gururaja <gururaja.hebbar@ti.com>]
- Resolve merge conflict while rebasing. File structure is
changed in the mainline. So re-arrange the code accordingly.
- Update commit message to reflect the DDR3 part number
Signed-off-by: Jeff Lance <j-lance1@ti.com> Signed-off-by: Tom Rini <trini@ti.com> Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
Lars Poeschel [Fri, 11 Jan 2013 00:53:32 +0000 (00:53 +0000)]
am335x: display msg when reading MAC from efuse
When ethaddr is not set in environment the MAC address is read
from efuse. The message was only printed in debug case, but this
message could be of interest for the ordinary user, so printf it.
Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
Lars Poeschel [Fri, 11 Jan 2013 00:53:31 +0000 (00:53 +0000)]
pcm051: Add support for Phytec phyCORE-AM335x
The board is named pcm051 and has this hardware:
SOC: TI AM3359
DDR3-RAM: 2x MT41J256M8HX-15EIT:D 512MiB
ETH 1: LAN8710AI
SPI-Flash: W25Q64BVSSIG
RTC: RV-4162-C7
I2C-EEPROM: CAT32WC32
NAND: MT29F4G08_VFPGA63
PMIC: TPS65910A3
LCD
Supported:
UART 1
MMC/SD
ETH 1
USB
I2C
SPI
Not yet supported:
NAND
RTC
LCD
Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
[trini: Add #define CONFIG_PHY_ADDR 0 to config] Signed-off-by: Tom Rini <trini@ti.com>
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>
Even when the IGEPv2 board and the IGEP Computer-on-Module
are different from a form factor point of view, they are
very similar in the fact that share many components and how
they are wired.
So, it is possible (and better) to have a single board file
for both devices and just use the CONFIG_MACH_TYPE to make
a differentiation between each board when needed.
This change avoids code duplication by removing 298 lines of
code and makes future maintenance easier.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Acked-by: Igor Grinberg <grinberg@compulab.co.il>
CONFIG_ARM_DCC_MULTI should be also removed in the patch
"serial: Remove CONFIG_SERIAL_MULTI from serial drivers"
(sha1: a3827250606895ec2dd4b8d867342b7cabf3692f)
Because the driver defines serial_* functions
which cause conflict with serial.c (multiple definition of serial_*)
Removing CONFIG_SERIAL_MULTI function also require to define
default_serial_console for cases where another serial driver
is not available in the system.
Signed-off-by: Michal Simek <michal.simek@xilinx.com> Acked-by: Marek Vasut <marex@denx.de>
Jim Lin [Thu, 24 Jan 2013 01:05:55 +0000 (01:05 +0000)]
console: USB: KBD: Fix incorrect autoboot timeout
Autoboot timeout defined by CONFIG_BOOTDELAY will not be accurate if
CONFIG_USB_KEYBOARD and CONFIG_SYS_USB_EVENT_POLL are defined in
configuration file and when tstc() function for checking key pressed
takes longer time than 10 ms (e.g., 50 ms) to finish.
Gabor Juhos [Sun, 6 Jan 2013 23:04:25 +0000 (23:04 +0000)]
common/cmd_bootm.c: prevent running of subcommands before 'bootm start'
The execution order of the bootm subcommands is fixed.
Although here is a sanity check in the state machine
which should prevent running the subcommands in wrong
order but it does not catch all possible errors.
It is possible to run any subcommand without running
'bootm start' first which leads to unexpected behaviour.
For example, running 'bootm loados' without 'bootm start'
causes a hang:
U-Boot> bootm loados
XIP Invalid Image ... OK
OK
Add a sanity check to 'do_bootm_subcommand' in order
to ensure that no subcommands can be executed before
'bootm start'.
After the patch running of any subcommand without running
'bootm start' will cause an error like this:
U-Boot> bootm loados
Trying to execute a command out of order
bootm - boot application image from memory
Alexey Brodkin [Thu, 3 Jan 2013 01:02:46 +0000 (01:02 +0000)]
drivers/block/systemace - fixed data type in "systemace_read" to match prototype in "block_dev_desc_t"
Currently we have "unsigned long blkcnt" which is fine with
CONFIG_SYS_64BIT_LBA undefined because "lbaint_t" is basically the same
"unsigned long".
If CONFIG_SYS_64BIT_LBA gets defined "lbaint_t" is defined as "unsigned
long long".
Even though not many embedded systems have CONFIG_SYS_64BIT_LBA defined
it's good to have types in function implementation that match exactly
with prototypes.
Richard Genoud [Thu, 13 Dec 2012 03:30:10 +0000 (03:30 +0000)]
FAT: remove ifdefs to make the code more readable
ifdefs in the code are making it harder to read.
The use of simple if(vfat_enabled) makes no more code and is cleaner.
(the code is discarded by the compiler instead of the preprocessor.)
NB: if -O0 is used, the code won't be discarded
and bonus, now the code compiles even if CONFIG_SUPPORT_VFAT is not
defined.
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>