If CONFIG_SYS_POST_I2C_ADDRS is not defined and CONFIG_SYS_POST_I2C
is activated, i2c_probe() is not called in the for statement,
because missing curly bracket.

Signed-off-by: Heiko Schocher <hs@denx.de>

Tested on upcoming hydra (mpc5200 based) board.

Signed-off-by: Heiko Schocher <hs@denx.de>

This has always been confusing, and the idea of these functions returning the
number of interfaces initialized was half-baked and ultimately pointless.
Instead, act more like regular functions and return < 0 on failure, >= 0 on
success.

This change shouldn't break anything.

Signed-off-by: Ben Warren <biggerbadderben@gmail.com>

Reorder including config.mk before the HOSTCC check, so HOSTCC is
actually defined when checking for it.

Signed-off-by: Franois Revol <revol@free.fr>

Cleaned up commit message
Signed-off-by: Wolfgang Denk <wd@denx.de>

Add a check to make sure that the user's arguments actually find a board
in boards.cfg.  Previously, if a user misspelled an argument the
argument would be discarded without warning.  For example, running
'MAKEALL -c 85xx' with the intention of compiling all Freescale 85xx
boards would instead silently discard the '-c 85xx' argument since the
proper cpu name is 'mpc85xx' and then proceed to compile all PowerPC
boards (MAKEALL's default).

Also fix an unrelated typo.

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>

When CONFIG_PCI_SCAN_SHOW is defined U-Boot prints out PCI devices as
they are found during bootup, eg:
  PCIE1: connected as Root Complex
        01:00.0 - 10b5:8518 - Bridge device
        02:01.0 - 10b5:8518 - Bridge device
        03:00.0 - 10b5:8112 - Bridge device
        04:01.0 - 8086:1010 - Network controller
        04:01.1 - 8086:1010 - Network controller
        02:02.0 - 10b5:8518 - Bridge device
        02:03.0 - 10b5:8518 - Bridge device
        06:00.0 - 10b5:8518 - Bridge device
        07:00.0 - 10b5:8518 - Bridge device
        08:00.0 - 1957:0040 - Processor
        07:01.0 - 10b5:8518 - Bridge device
        09:00.0 - 10b5:8112 - Bridge device
        07:02.0 - 10b5:8518 - Bridge device
  PCIE1: Bus 00 - 0b
  PCIE2: connected as Root Complex
        0d:00.0 - 1957:0040 - Processor
  PCIE2: Bus 0c - 0d

This information is useful, but its difficult to determine the PCI bus
topology.  To things clearer, we can use indention to make it more
obvious how the PCI bus is organized.  For the example above, the
updated output with this change is:

  PCIE1: connected as Root Complex
    01:00.0     - 10b5:8518 - Bridge device
     02:01.0    - 10b5:8518 - Bridge device
      03:00.0   - 10b5:8112 - Bridge device
       04:01.0  - 8086:1010 - Network controller
       04:01.1  - 8086:1010 - Network controller
     02:02.0    - 10b5:8518 - Bridge device
     02:03.0    - 10b5:8518 - Bridge device
      06:00.0   - 10b5:8518 - Bridge device
       07:00.0  - 10b5:8518 - Bridge device
        08:00.0 - 1957:0040 - Processor
       07:01.0  - 10b5:8518 - Bridge device
        09:00.0 - 10b5:8112 - Bridge device
       07:02.0  - 10b5:8518 - Bridge device
  PCIE1: Bus 00 - 0b
  PCIE2: connected as Root Complex
    0d:00.0     - 1957:0040 - Processor
  PCIE2: Bus 0c - 0d

In the examples above, an MPC8640 is connected to a PEX8518 PCIe switch
(01:00 and 02:0x), which is connected to another PEX8518 PCIe switch
(06:00 and 07:0x), which then connects to a MPC8572 processor (08:00).
Also, the MPC8640's PEX8518 PCIe switch is connected to a PCI ethernet
card (04:01) via a PEX8112 PCIe-to-PCI bridge (03:00).

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>

Move the printing of PCI device information to before the PCI device is
configured.  This prevents the case where recursive scanning results in
the deepest devices being printed first.

This change also makes PCI lockups during enumeration easier to
diagnose since the device that is being configured is printed out prior
to configuration.  Previously, it was not possible to determine which
device caused the PCI lockup.

Original example:
  PCIE1: connected as Root Complex
        04:01.0 - 8086:1010 - Network controller
        04:01.1 - 8086:1010 - Network controller
        03:00.0 - 10b5:8112 - Bridge device
        02:01.0 - 10b5:8518 - Bridge device
        02:02.0 - 10b5:8518 - Bridge device
        08:00.0 - 1957:0040 - Processor
        07:00.0 - 10b5:8518 - Bridge device
        09:00.0 - 10b5:8112 - Bridge device
        07:01.0 - 10b5:8518 - Bridge device
        07:02.0 - 10b5:8518 - Bridge device
        06:00.0 - 10b5:8518 - Bridge device
        02:03.0 - 10b5:8518 - Bridge device
        01:00.0 - 10b5:8518 - Bridge device
  PCIE1: Bus 00 - 0b

Updated example:
  PCIE1: connected as Root Complex
        01:00.0 - 10b5:8518 - Bridge device
        02:01.0 - 10b5:8518 - Bridge device
        03:00.0 - 10b5:8112 - Bridge device
        04:01.0 - 8086:1010 - Network controller
        04:01.1 - 8086:1010 - Network controller
        02:02.0 - 10b5:8518 - Bridge device
        02:03.0 - 10b5:8518 - Bridge device
        06:00.0 - 10b5:8518 - Bridge device
        07:00.0 - 10b5:8518 - Bridge device
        08:00.0 - 1957:0040 - Processor
        07:01.0 - 10b5:8518 - Bridge device
        09:00.0 - 10b5:8112 - Bridge device
        07:02.0 - 10b5:8518 - Bridge device
  PCIE1: Bus 00 - 0b

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>

This change does the following:
- Removes the printing of the PCI interrupt line value.  This is
  normally set to 0 by U-Boot on bootup and is rarely used during
  everyday operation.

- Prints out the PCI function number of a device.  Previously a device
  with multiple functions would be printed identically 2 times, which is
  generally confusing.  For example, on an Intel 2 port gigabit Ethernet
  card the following was displayed:
    ...
    04  01  8086  1010  0200  00
    04  01  8086  1010  0200  00
    ...

- Prints a text description of each device's PCI class instead of the
  raw PCI class code.  The textual description makes it much easier to
  determine what devices are installed on a PCI bus.

- Changes the general formatting of the PCI device output.

Previous output:
  PCIE1: connected as Root Complex
          04  01  8086  1010  0200  00
          04  01  8086  1010  0200  00
          03  00  10b5  8112  0604  00
          02  01  10b5  8518  0604  00
          02  02  10b5  8518  0604  00
          08  00  1957  0040  0b20  00
          07  00  10b5  8518  0604  00
          09  00  10b5  8112  0604  00
          07  01  10b5  8518  0604  00
          07  02  10b5  8518  0604  00
          06  00  10b5  8518  0604  00
          02  03  10b5  8518  0604  00
          01  00  10b5  8518  0604  00
  PCIE1: Bus 00 - 0b
  PCIE2: connected as Root Complex
          0d  00  1957  0040  0b20  00
  PCIE2: Bus 0c - 0d

Updated output:
  PCIE1: connected as Root Complex
          04:01.0 - 8086:1010 - Network controller
          04:01.1 - 8086:1010 - Network controller
          03:00.0 - 10b5:8112 - Bridge device
          02:01.0 - 10b5:8518 - Bridge device
          02:02.0 - 10b5:8518 - Bridge device
          08:00.0 - 1957:0040 - Processor
          07:00.0 - 10b5:8518 - Bridge device
          09:00.0 - 10b5:8112 - Bridge device
          07:01.0 - 10b5:8518 - Bridge device
          07:02.0 - 10b5:8518 - Bridge device
          06:00.0 - 10b5:8518 - Bridge device
          02:03.0 - 10b5:8518 - Bridge device
          01:00.0 - 10b5:8518 - Bridge device
  PCIE1: Bus 00 - 0b
  PCIE2: connected as Root Complex
          0d:00.0 - 1957:0040 - Processor
  PCIE2: Bus 0c - 0d

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>

The "Scanning PCI bus X" message doesn't provide any real useful
information, so remove it.

Original output:
  PCIE1: connected as Root Complex
             Scanning PCI bus 01
          04  01  8086  1010  0200  00
          04  01  8086  1010  0200  00
          03  00  10b5  8112  0604  00
          02  01  10b5  8518  0604  00
          02  02  10b5  8518  0604  00
          08  00  1957  0040  0b20  00
          07  00  10b5  8518  0604  00
          09  00  10b5  8112  0604  00
          07  01  10b5  8518  0604  00
          07  02  10b5  8518  0604  00
          06  00  10b5  8518  0604  00
          02  03  10b5  8518  0604  00
          01  00  10b5  8518  0604  00
  PCIE1: Bus 00 - 0b
  PCIE2: connected as Root Complex
             Scanning PCI bus 0d
          0d  00  1957  0040  0b20  00
  PCIE2: Bus 0c - 0d

Updated output:
  PCIE1: connected as Root Complex
          04  01  8086  1010  0200  00
          04  01  8086  1010  0200  00
          03  00  10b5  8112  0604  00
          02  01  10b5  8518  0604  00
          02  02  10b5  8518  0604  00
          08  00  1957  0040  0b20  00
          07  00  10b5  8518  0604  00
          09  00  10b5  8112  0604  00
          07  01  10b5  8518  0604  00
          07  02  10b5  8518  0604  00
          06  00  10b5  8518  0604  00
          02  03  10b5  8518  0604  00
          01  00  10b5  8518  0604  00
  PCIE1: Bus 00 - 0b
  PCIE2: connected as Root Complex
          0d  00  1957  0040  0b20  00
  PCIE2: Bus 0c - 0d

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
CC: galak@kernel.crashing.org

Previously some mpc85xx boards printed indented messages such as the
following on bootup:
  printf("    eTSEC4 is in sgmii mode.\n");
  printf("    Serdes2 disalbed\n");

The bootup appearance looks cleaner if the indentation is removed which
aligns these messages with other bootup output.

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
CC: galak@kernel.crashing.org

Previously boards used a variety of indentations, newline styles, and
colon styles for the PCI information that is printed on bootup.  This
patch unifies the style to look like:

...
NAND:  1024 MiB
PCIE1: connected as Root Complex
           Scanning PCI bus 01
        04  01  8086  1010  0200  00
        04  01  8086  1010  0200  00
        03  00  10b5  8112  0604  00
        02  01  10b5  8518  0604  00
        02  02  10b5  8518  0604  00
        08  00  1957  0040  0b20  00
        07  00  10b5  8518  0604  00
        09  00  10b5  8112  0604  00
        07  01  10b5  8518  0604  00
        07  02  10b5  8518  0604  00
        06  00  10b5  8518  0604  00
        02  03  10b5  8518  0604  00
        01  00  10b5  8518  0604  00
PCIE1: Bus 00 - 0b
PCIE2: connected as Root Complex
           Scanning PCI bus 0d
        0d  00  1957  0040  0b20  00
PCIE2: Bus 0c - 0d
In:    serial
...

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
CC: wd@denx.de
CC: sr@denx.de
CC: galak@kernel.crashing.org

Previously fsl_pci_init_port() always assumed that a port was a PCIe
port and would incorrectly print messages for a PCI port such as the
following on bootup:
    PCI1:  32 bit, 33 MHz, sync, host, arbiter
                Scanning PCI bus 00
    PCIE1 on bus 00 - 00

This change corrects the output of fsl_pci_init_port():
    PCI1:  32 bit, 33 MHz, sync, host, arbiter
                Scanning PCI bus 00
    PCI1 on bus 00 - 00

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>

Can't get IP address with dhcp due to the dhcp server not
allow the empty param list request under some network env

This patch is based on Gray Remlin's initial patch.

Signed-off-by: Jason Liu <r64343@freescale.com>
Signed-off-by: Gray Remlin <g_remlin@rocketmail.com>

hexport would complain implicit declaration, if we don't add the
include file.

env_mmc.c: In function 'saveenv':
env_mmc.c:109: warning: implicit declaration of function 'hexport'

Signed-off-by: Lei Wen <leiwen@marvell.com>

This patch makes tools/env/Makefile more similar to tools/imls:
- define HOSTSRCS and HOSTCPPFLAGS, so that .depend generation works.
- include U-Boot headers using -idirafter to prevent picking up
  u-boot/include/errno.h.
- use HOSTCFLAGS_NOPED (fw_env.c does not conform to -pedantic).

In order to cross-compile tools/env, override the HOSTCC variable
as in this example:

  make tools env HOSTCC=bfin-uclinux-gcc

Signed-off-by: Daniel Hobi <daniel.hobi@schmid-telecom.ch>
Tested-by: Detlev Zundel <dzu@denx.de>
Tested-by: Steve Sakoman <steve.sakoman@linaro.org>

The fixup procedure just stored a constant value in the
fixup table rather than just adjusting the table.
Although that doesn't seem to do any harm, it prevents
relocation more that once.

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>

nic and hw structures are allocated via malloc i.e. return memory
is not zero initialized. Because of this few structure member like
"function pointers" are initialized with garbage values.

It may cause problem. for eg. during eth_initialize, dev->write_hwaddr
is used.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Fixed typo.
Signed-off-by: Wolfgang Denk <wd@denx.de>

uli526x driver does not have write_hwaddr function.
However, eth stuff executes write_hwaddr function
because eth_device structure has not been initialized.

Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
CC: Ben Warren <biggerbadderben@gmail.com>

tsi108_eth driver does not have write_hwaddr function.
However, eth stuff executes write_hwaddr function
because eth_device structure has not been initialized.

Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
CC: Ben Warren <biggerbadderben@gmail.com>

pcnet driver does not have write_hwaddr function.
However, eth stuff executes write_hwaddr function
because eth_device structure has not been initialized.

Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
CC: Ben Warren <biggerbadderben@gmail.com>

ns8382x driver does not have write_hwaddr function.
However, eth stuff executes write_hwaddr function
because eth_device structure has not been initialized.

Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
CC: Ben Warren <biggerbadderben@gmail.com>

natsemi driver does not have write_hwaddr function.
However, eth stuff executes write_hwaddr function
because eth_device structure has not been initialized.

Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
CC: Ben Warren <biggerbadderben@gmail.com>

This prevents access to the member of eth_device which is not initialized.

Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
CC: Ben Warren <biggerbadderben@gmail.com>

eepro100 driver does not have write_hwaddr function.
However, eth stuff executes write_hwaddr function
because eth_device structure has not been initialized.

Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
CC: Ben Warren <biggerbadderben@gmail.com>

dc2114x driver does not have write_hwaddr function.
However, eth stuff executes write_hwaddr function
because eth_device structure has not been initialized.

Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
CC: Ben Warren <biggerbadderben@gmail.com>

rtl8139 driver does not have write_hwaddr function.
However, eth stuff executes write_hwaddr function
because eth_device structure has not been initialized.

Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
CC: Ben Warren <biggerbadderben@gmail.com>

rtl8169 does not have write_hwaddr function.
However, eth stuff executes write_hwaddr function
because eth_device structure has not been initialized.

Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
CC: Ben Warren <biggerbadderben@gmail.com>

The size of the other bank needed to be added to the br0 setting;
this got dropped in the LBC cleanup.

Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
Tested-by: Wolfgang Denk <wd@denx.de>
Acked-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Display the 64-byte Reset Configuration Word (RCW) during boot, so that
there's no confusion as to what RCW U-boot is using.

Reset Configuration Word (RCW):
       00000000: 4a500000 00000000 18181818 00008888
       00000010: 28402400 00002000 fe800000 01200000
       00000020: 00000000 00000000 00000000 000b0000
       00000030: 00000000 00000000 00000000 00000000

Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

We appear to have different refclk's on the different corenet DS boards
so move the define out of the common header.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

CONFIG_SYS_TEXT_BASE setting is common across the 'corenet_ds' board
family so move it out of P4080DS.h and into corenet_ds.h

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

SQW/INT pin in RTC can be used for generating square wave(by default) or
as interrupt line.  U-boot is registering this pin for interrupts.
Configuring SQW/INT bit as interrupt line during board initialization
to avoid spurious interrupts generated by square wave.

Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Introduce a SPL specific CONFIG_SYS_TEXT_BASE_SPL define to be used by
the linker.  This has similiar semantics to CONFIG_SYS_TEXT_BASE however
since SPL is a unqiue image we introduce a new variable to control its
text base address.

Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Use CONFIG_SYS_MONITOR_BASE instead of CONFIG_SYS_TEXT_BASE in early
init code so we can share the same code with NAND or NOR boot and not
have additional ifdefs in here.

Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Fix u-boot-nand.lds and u-boot-nand_spl.lds according to:

Author: Peter Tyser <ptyser@xes-inc.com>
Date:   Wed Sep 29 14:05:56 2010 -0500
commit fbe53f59
    85xx: Use gc-sections to reduce image size

Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>