Every now and then a Sequoia board (or equivalent hardware) had
problems connecting to a Gigabit capable network interface.

There were differences in the PHY setup between Linux and U-Boot.

This patch fixes the problem. Apparently "remote fault" is being set,
which signals to some devices (on the other end of the cable) that a
fault has occurred, while other devices ignore it. I believe the RF bit
was causing the issue, but I removed T4 also, to match up with Linux.

Signed-off-by: Mike Nuss <mike@terascala.com>

The 405EZ only supports 512 bytes of rx-/tx-fifo EMAC sizes. But
currently 4k/2k is configured. This patch fixes this issue.

Thanks to Thomas Kindler <tkindler@lenord.de> for pointing this out.

Signed-off-by: Stefan Roese <sr@denx.de>

Adds PCI support for MPC5121

Tested with drivers/net/rtl8139.c

Support is conditional since PCI on old silicon does not work.

ads5121_PCI_config turns on PCI

In this version, condition compilation of PCI code has been moved
from ifdef in board/ads5121/pci.c to board/ads5121/Makefile as
suggested by Jean-Christophe PLAGNIOL-VILLARD

Signed-off-by: John Rigby <jrigby@freescale.com>

U-Boot crashes in the net loop if CONFIG_4xx_DCACHE is
enabled. To reproduce the problem ensure that 'ethrotate'
environment variable isn't set to "no" and then run
"tftp 200000 not_existent_file".
This patch tries to fix the issue.

Signed-off-by: Anatolij Gustschin <agust@denx.de>

There is no reason to icbi when invalidating the temporary stack in
the d-cache.  Its impossible on e500 to have the i-cache contain
any addresses in the temp stack and it can be problematic in generating
transactions on the bus to non-valid addresses.

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

The source vector for the ECM was being set to 2,
but that's what the source vector for DDR was being
set to.  Change it to 1.

Signed-off-by: Andy Fleming <afleming@freescale.com>

Commit 0db37dc...  (and some others) changed the INIT_RAM TLB
mappings to be unguarded.  This collided with an existing "bug"
where the mappings for the INIT_RAM were being kept around.
This meant that speculative loads to those addresses were
succeeding in the TLB, and going out to the bus, where they
were causing an exception (there's nothing at that address). The
Flash code was coincidentally causing such a speculative load.
Rather than go back to mapping the INIT RAM as guarded, we fix
it so that the entries for the INIT_RAM are invalidated.  Thus
the speculative loads will fail in the TLB, and have no effect.

Signed-off-by: Andy Fleming <afleming@freescale.com>

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

This will reduce the build time.

Signed-off-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>