Age | Commit message (Collapse) | Author |
|
Signed-off-by: Stefan Roese <sr@denx.de>
|
|
This patch adds support for 405 PPC's to the 4xx NAND driver
ndfc.c. This is in preparation for the new AMCC 405EZ.
Signed-off-by: Stefan Roese <sr@denx.de>
|
|
As spotted by Bruce Adler this patch fixes an initialization problem
for the 405EZ OCM.
Signed-off-by: Stefan Roese <sr@denx.de>
|
|
|
|
Signed-off-by: Stefano Babic <sbabic@denx.de>
|
|
Because the Sequoia board does not boot with an EBC faster than 66MHz,
the clock divider are changed after the initial boot process.
This allows for maximum clocking speeds to be achieved on newer boards.
Sequoia boards with 666.66 MHz processors require that the EBC divider
be set to 3 in order to start the initial boot process at a slower EBC
speed. After the initial boot process, the divider can be set back to 2,
which will cause the boards to run at 83.333MHz. This is backward
compatible with boards with 533.33 MHz processors, as these boards will
already be set with an EBC divider of 2.
Signed-off-by: Jeffrey Mann <mannj@embeddedplanet.com>
|
|
Signed-off-by: Wolfgang Denk <wd@denx.de>
|
|
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Stefan Roese <sr@denx.de>
|
|
Signed-off-by: Stefan Roese <sr@denx.de>
|
|
definition.
|
|
|
|
|
|
|
|
|
|
environment.
|
|
eliminates networking problems in Linux (timeouts).
|
|
to allow booting of FDT-expecting kernels.
|
|
Conflicts:
include/asm-microblaze/microblaze_intc.h
include/linux/stat.h
|
|
|
|
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.
|
|
Signed-off-by: Wolfgang Denk <wd@denx.de>
|
|
Signed-off-by: Wolfgang Denk <wd@denx.de>
|
|
|
|
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>
|
|
FSL_Has_data is connected to INTC.
|
|
remove asm code
|
|
|
|
|
|
|
|
|
|
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>
|
|
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Acked-by: Stefan Roese <sr@denx.de>
|
|
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>
|
|
|
|
|
|
Signed-off-by: Wolfgang Denk <wd@denx.de>
|
|
|
|
Signed-off-by: Wolfgang Denk <wd@denx.de>
|
|
|
|
|
|
|
|
|