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>
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>
In case that there is no memory based bad block table available the
function nand_block_checkbad() in drivers/mtd/nand/nand_base.c will call
nand_block_bad() directly. When parameter 'getchip' is set to zero,
nand_block_bad() will not right shift the offset to calculate the
correct page number.
Signed-off-by: Thomas Knobloch <knobloch@siemens.com>
Signed-off-by: Stefan Roese <sr@denx.de>
When bringing up u-boot on new boards, PHY support sometimes gets
neglected. Most PHYs don't really need any special support,
though. By adding a generic entry that always matches if nothing
else does, we can provide support for "unsupported" PHYs for the
tsec.
The generic PHY driver supports most PHYs, including gigabit.
Signed-off-by: David Updegraff <dave@cray.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
* Add support to the Makefile
* Add 8544 configuration support to the tsec driver
* Add 8544 SVR numbers to processor.h
Signed-off-by: Ed Swarthout <Ed.Swarthout@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Driver for the Atmel MACB on-chip ethernet controller.
This driver has been tested on the ATSTK1000 board with a AT32AP7000
CPU. It should probably work on AT91SAM926x as well with some minor
modifications.
Hardware documentation can be found in the AT32AP7000 data sheet,
which can be downloaded from
http://www.atmel.com/dyn/products/datasheets.asp?family_id=682
Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
Rewrite the resource management code (i.e. I/O memory, clock gating,
gpio) so it doesn't depend on any global state. This is necessary
because this code is heavily used before relocation to RAM, so we
can't write to any global variables.
As an added bonus, this makes u-boot's memory footprint a bit smaller,
although some functionality has been left out; all clocks are enabled
all the time, and there's no checking for gpio line conflicts.
Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
Fix empty i2c reads/writes, i2c_write(0x50, 0x00, 0, NULL, 0)
which is used to se if an slave will ACK after receiving its address.
Correct i2c probing to use this method as the old method could upset
a slave as it wrote a data byte to it.
Add a small delay in i2c_init() to let the controller
shutdown any ongoing I2C activity.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
The problem is not gcc4 but the code itself. The BD_STATUS() macro can't
be used for busy-waiting since it strips the 'volatile' property from
the bd variable. gcc3 was working by pure luck.
This is a follow on patch to "Fix the UEC driver bug of QE"
I've redone the SBC8349 support to match git-current, which
incorporates all the MPC834x updates from Freescale since the 1.1.6
release, including the DDR changes.
I've kept all the SBC8349 files as parallel as possible to the
MPC8349EMDS ones for ease of maintenance and to allow for easy
inspection of what was changed to support this board. Hence the SBC8349
U-Boot has FDT support and everything else that the MPC8349EMDS has.
Fortunately the Freescale updates added support for boards using CS0,
but I had to change spd_sdram.c to allow for board specific settings for
the sdram_clk_cntl (it is/was hard coded to zero, and that remains the
default if the board doesn't specify a value.)
Hopefully this should be mergeable as-is and require no whitespace
cleanups or similar, but if something doesn't measure up then let me
know and I'll fix it.
Thanks,
Paul.
The patch prevents the GCC tool chain from striping useful code for
optimization. It will make UEC ethernet driver workable, Otherwise the
UEC will fail in tx when you are using gcc4.x. but the driver can work
when using gcc3.4.3.
CHANGELOG
*Prevent the GCC from striping code for optimization, Otherwise the UEC
will tx failed when you are using gcc4.x.
Signed-off-by: Dave Liu <daveliu@freescale.com>
As suggested by Grant Likely this patch enables the Xilinx SystemACE
driver to select 8 or 16bit mode upon startup.
Signed-off-by: Stefan Roese <sr@denx.de>
Some CPUs like PPC, BLACKFIN need sync() to ensure cfi flash write command
is fully finished. The sync() is defined in each CPU's io.h file. For
those CPUs which do not need sync for now, a dummy sync() is defined in
their io.h as well.
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
This patch removes some problems when the Xilinx SystemACE driver
is used with 16bit access on an big endian platform (like the
AMCC Katmai).
Signed-off-by: Stefan Roese <sr@denx.de>
Block device read/write is anonymous data; there is no need to use a
typed pointer. void * is fine. Also add a hook for block_read functions
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Register read/write does not need to be wrapped in a full function. The
patch replaces them with macros.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
The code in this file is not a command; it is a device driver. Put it in
the correct place. There are zero functional changes in this patch, it
only moves the file.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Conflicts:
drivers/cfi_flash.c
The patch by Heiko Schocher <hs@pollux.denx.de> on Jan, 19, 2007
fixes cfi_driver bug for mpc7448hpc2 board. The default cfi_driver can support
mpc7448hpc2 board.
Here the description from Brian Brelsford <Brian_Brelsford@dell.com>:
The Hynix part returns a 0x1d in the 4th ID byte. The Samsung part
returns a 0x15. In the code fragment below bits [1:0] determine the
page size, it is ANDed via "(extid & 0x3)" then shifted out. The
next field is also ANDed with 0x3. However this is a one bit field
as defined in the Hynix and Samsung parts in the 4th ID byte that
determins the oobsize, not a two bit field. It works on Samsung as
bits[3:2] are 01. However for the Hynix there is a 11 in these two
bits, so the oob size gets messed up.
I checked the correct linux code and the suggested fix from Brian is
also available in the linux nand mtd driver.
Signed-off-by: Stefan Roese <sr@denx.de>
The conflicts due to a new mpc7448 p3m7448 board is in the main tree.
Merge branch 'master' into hpc2
Conflicts:
MAKEALL
cpu/74xx_7xx/cpu.c
cpu/74xx_7xx/cpu_init.c
cpu/74xx_7xx/speed.c
(1) remove some C++ comments.
(2) remove trailing white space.
(3) remove trailing empty line.
(4) Indentation by table.
(5) remove {} in one line condition.
(6) add space before '(' in function call.
Remove some weird printf () output.
Add necessary comments.
Modified Makefile to support building in a separate directory.
