The OBJTREE != SRCTREE build scenario was broken.
This fixes it.
Signed-off-by: Ed Swarthout <Ed.Swarthout@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
current PHY initalization code (tftp timeouts all the time). This commit
temporarily disables PHY initalization sequence to make the networking
operational, until a fix is found.
A '3' got cut off in the formatting of the last patch to automatically
change the clock speed of the system clock on sequoia board.
Signed-off-by: Jeffrey Mann <mannj@embeddedplanet.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Some device trees have a mac-address property, some have local-mac-address,
and some have both. To support all of these device trees, ftp_cpu_setup()
should write the MAC address to mac-address and local-mac-address, if they
exist.
Signed-off-by: Timur Tabi <timur@freescale.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
MPC5200B systems are incorrectly reported as MPC5200 in U-Boot start-up
message. Use PVR to distinguish between the two variants, and print proper CPU
information.
Signed-off-by: Grzegorz Wianecki <grzegorz.wianecki@gmail.com>
Signed-off-by: Bartlomiej Sieka <tur@semihalf.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
If a PCI IDE card happens to get a zero address assigned to it, the Linux IDE
core complains and IDE drivers fails to work. Also, assigning zero to a BAR
was illegal according to PCI 2.1 (the later revisions seem to have excluded the
sentence about "0" being considered an invalid address) -- so, use a reasonable
starting value of 0x1000 (that's what the most Linux archs are using).
Alternatively, one might have fixed the calls to pci_set_region() individually
(some code even seems to have taken care of this issue) but that would have
been a lot more work. :-)
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: Stefan Roese <sr@denx.de>
update setenv() function so that entering a NULL value for the
variable's value will delete the environmental variable
Signed-off-by: Jeffrey Mann <mannj@embeddedplanet.com>
Acked-by: Stefan Roese <sr@denx.de>
the v_mac variable in the smc91111 driver is declared as a signed char ...
this causes problems when one of the bytes in the MAC is "signed" like 0xE0
because when it gets printed out, you get a display like:
0xFFFFFFE0 and that's no good
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Wolfgang Denk