Embedd chip select configuration into struct for gpmc config
instead of having it completely separated as suggested by
Wolfgang Denk on
http://lists.denx.de/pipermail/u-boot/2009-May/052247.html
Signed-off-by: Matthias Ludwig <mludwig@ultratronik.de>
For some reason the AT91rm9200 lowlevel init writes to a bunch of
reserved or read-only addresses. All the boards seem to define the
value-to-be-written values as zero ... but they shouldn't actually
be writing *anything* there.
No documented erratum justifies these accesses. It looks like maybe
some pre-release BDI-2000 setup code has been carried along by cargo
cult programming since at least late 2004 (per GIT history).
Here's a patch disabling what seems to be bogosity. Tested on a
csb337; there were no behavioral changes.
Signed-off-by: David Brownell <david-b@pacbell.net>
on RM9200ek
Tested-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Commit 70ebf316 factored out the ROUND() macro into include/common.h,
not realizing that the primary use of this macro on AT91 systems was
in start.S where common.h was not included, and could not be included
because it contains a lot of C code which the assembler doesn't
understand.
This patch wraps such code in common.h in a "#ifndef __ASSEMBLY__"
construct, and then adds an include to cpu/arm926ejs/start.S thus
solving the problem.
Signed-off-by: Wolfgang Denk <wd@denx.de>
This patch adds support for the AVR32 LCD controller. This patch is
based off the latest u-boot-video.
A quick summary of what's going on:-
Enable LCDC pixel clock
Enable LCDC port pins
Add framebuffer pointer to global_data struct
Allocate framebuffer
To use the new code, update your board config to include something like
this:-
#define CONFIG_LCD 1
#if defined(CONFIG_LCD)
#define CONFIG_CMD_BMP
#define CONFIG_ATMEL_LCD 1
#define LCD_BPP LCD_COLOR16
#define CONFIG_BMP_16BPP 1
#define CONFIG_FB_ADDR 0x10600000
#define CONFIG_WHITE_ON_BLACK 1
#define CONFIG_VIDEO_BMP_GZIP 1
#define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE 262144
#define CONFIG_ATMEL_LCD_BGR555 1
#define CONFIG_SYS_CONSOLE_IS_IN_ENV 1
#define CONFIG_SPLASH_SCREEN 1
#endif
The standard U-Boot BMP and Splash-screen features should just work.
Signed-off-by: Mark Jackson <mpfj@mimc.co.uk>
[agust@denx.de: fixed some style issues]
Signed-off-by: Anatolij Gustschin <agust@denx.de>
This patch adds a generic command for programming I2C bootstrap
eeproms on PPC4xx. An implementation for Canyonlands board is
included.
The command name is intentionally chosen not to be PPC4xx specific.
This way other CPU's/SoC's can implement a similar command under
the same name, perhaps with a different syntax.
Usage on Canyonlands:
=> chip_config
Available configurations (I2C address 0x52):
600-nor - NOR CPU: 600 PLB: 200 OPB: 100 EBC: 100
600-nand - NAND CPU: 600 PLB: 200 OPB: 100 EBC: 100
800-nor - NOR CPU: 800 PLB: 200 OPB: 100 EBC: 100
800-nand - NAND CPU: 800 PLB: 200 OPB: 100 EBC: 100
1000-nor - NOR CPU:1000 PLB: 200 OPB: 100 EBC: 100
1000-nand - NAND CPU:1000 PLB: 200 OPB: 100 EBC: 100
1066-nor - NOR CPU:1066 PLB: 266 OPB: 88 EBC: 88 ***
1066-nand - NAND CPU:1066 PLB: 266 OPB: 88 EBC: 88
=> chip_config 600-nor
Using configuration:
600-nor - NOR CPU: 600 PLB: 200 OPB: 100 EBC: 100
done (dump via 'i2c md 52 0.1 10')
Reset the board for the changes to take effect
Other 4xx boards will be migrated to use this command soon
as well.
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Dirk Eibach <eibach@gdsys.de>
Acked-by: Matthias Fuchs <matthias.fuchs@esd.eu>
In cpu/ppc4xx/speed.c initialization of sysInfo->freqOPB for 405EP was
left out for no obvious reason.
Signed-off-by: Dirk Eibach <eibach@gdsys.de>
Signed-off-by: Stefan Roese <sr@denx.de>
Patch d873133f [ppc4xx: Add Sequoia RAM-booting target] broke "normal"
booting on some 44x platforms. This breakage is only noticed in some
cases while powercycling. As it seems, the code in question in start.S
didn't invalidate TLB #0. This makes sense since this TLB is used for
the bootrom mapping. With the patch mentioned above even TLB #0 got
invalidated resulting in an error later on.
This patch now fixes this issue by only invalidating TLB #0 in the RAM-
booting case.
Tested succesfully on Sequoia and Canyonlands.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Dirk Eibach <Eibach@gdsys.de>
The top build system sets up HOSTCFLAGS a bit and exports it, but other
places use HOST_CFLAGS instead. Unify the two as HOSTCFLAGS so that the
values stay in sync.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
CSB337 boards originally shipped with MicroMonitor, not U-Boot;
and with a version using a different convention for recording
Ethernet addresses than anyone else. To avoid breaking Linux
when it uses U-Boot, have it use the same convention on that
hardware.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Ben Warren <biggerbadderben@gmail.com>
Because of the reset_cpu is soc specific, should be move to soc
Cc: Dirk Behme <dirk.behme@googlemail.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Previously, 85xx and 86xx boards would display DRAM information on
bootup such as:
...
I2C: ready
DRAM:
Memory controller interleaving enabled: Bank interleaving!
2 GB
FLASH: 256 MB
...
This patch moves the printing of the DRAM controller configuration to a
common board_add_ram_info() function which prints out DDR type, width,
CAS latency, and ECC mode. It also makes the DDR interleaving
information print out in a more sane manner:
...
I2C: ready
DRAM: 2 GB (DDR2, 64-bit, CL=4, ECC on)
DDR Controller Interleaving Mode: bank
FLASH: 256 MB
...
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Rename sdram_mode_1 to sdram_mode and sdram_cfg_1 to sdram_cfg to match
the 86xx user's manual and other Freescale architectures
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Part of the mini Blackfin ABI with operating systems is that they can use
0x4f0-0x4f8 to pass log buffers to/from bootloaders. So add support to
U-Boot for reading the log buffer.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
On build of omap3 targets in MAKEALL, the *.ERR files have
cpu.c: In function 'cleanup_before_linux':
cpu.c:64: warning: implicit declaration of function 'v7_flush_dcache_all'
cpu.c:64: warning: implicit declaration of function 'get_device_type
The functions v7_flush_dcache_all and get_device_type are declared
in include/asm-arm/arch-omap3/sys_proto.h, so use this file to
declare the functions.
Signed-off-by: Tom Rix <Tom.Rix@windriver.com>
So far the console API uses the following naming convention:
======Extract======
typedef struct device_t;
int device_register (device_t * dev);
int devices_init (void);
int device_deregister(char *devname);
struct list_head* device_get_list(void);
device_t* device_get_by_name(char* name);
device_t* device_clone(device_t *dev);
=======
which is too generic and confusing.
Instead of using device_XX and device_t we change this
into stdio_XX and stdio_dev
This will also allow to add later a generic device mechanism in order
to have support for multiple devices and driver instances.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Edited commit message.
Signed-off-by: Wolfgang Denk <wd@denx.de>
Remove individual CPU specific DSPI driver.
Add required feature for the common DSPI driver in cpu_init and
in platform configuration file.
Signed-off-by: TsiChung Liew <tsicliew@gmail.com>
Update serial boot DRAM's Internal RAM, vector table and DRAM in
start.S, serial flash's read status command over SPI and NOR
flash.
Signed-off-by: TsiChung Liew <tsicliew@gmail.com>
Now that we have 3 boards for the MPC512x it turns out that they all
use the very same fixed_sdram() code.
This patch factors out this common code into cpu/mpc512x/fixed_sdram.c
and adds a new header file, include/asm-ppc/mpc512x.h, with some
macros, inline functions and prototype definitions specific to MPC512x
systems.
Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Stefan Roese <sr@denx.de>
Cc: Reinhard Arlt <reinhard.arlt@esd-electronics.com>
AT91sam9g10 is an ARM 926ej-s SOC. It is an evolution of the at91sam9261 with a
faster clock speed: 266/133MHz.
Signed-off-by: Sedji Gaouaou <sedji.gaouaou@atmel.com>
AT91sam9g45 series is an ARM 926ej-s SOC family clocked at 400/133MHz.
It embeds USB high speed host and device, LCD, DDR2 RAM, and a full set of
peripherals.
The first board that embeds at91sam9g45 chip is the AT91SAM9G45-EKES.
On the board you can find 2 USART, USB high speed,
a 480*272 LG lcd, ethernet, gpio/joystick/buttons.
Signed-off-by: Sedji Gaouaou <sedji.gaouaou@atmel.com>
Add support for the Phytec phyCORE-MPC5200B-tiny.
Code originally from Pengutronix.de.
Created CONFIG_SYS_ATA_CS_ON_TIMER01 define for when IDE CS is on
Timer 0/1
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Current code only sets the PCI vendor id to 0x1014 and
leaved device id to 0x0000.
Ths patch ....
a) uses the correct PCI_VENDOR_ID_IBM macro for this
b) sets the default device ID as stated in the UM to 0x0156
by using PCI_DEVICE_ID_IBM_405GP for this.
Signed-off-by: Matthias Fuchs <matthias.fuchs@esd.eu>
Signed-off-by: Stefan Roese <sr@denx.de>
This patch moves some basic PCI initialisation from the 4xx cpu_init_f()
to cpu/ppc4xx/4xx_pci.c.
The original cpu_init_f() function enabled the 405EP's internal arbiter
in all situations. Also the HCE bit in cpc0_pci is always set.
The first is not really wanted for PCI adapter designs and the latter
is a general bug for PCI adapter U-Boots. Because it enables
PCI configuration by the system CPU even when the PCI configuration has
not been setup by the 405EP. The one and only correct place is
in pci_405gp_init() (see "Set HCE bit" comment).
So for compatibility reasons the arbiter is still enabled in any case,
but from weak pci_pre_init() so that it can be replaced by board specific
code.
Signed-off-by: Matthias Fuchs <matthias.fuchs@esd.eu>
Signed-off-by: Stefan Roese <sr@denx.de>
It fixes the access to the 'ehci' struct elements for mpc83xx which
should have been taken care of in 4ef01010aa
Sorry about that.
Signed-off-by: Vivek Mahajan <vivek.mahajan@freescale.com>
Signed-off-by: Remy Bohmer <linux@bohmer.net>
This patch makes pll_write on PPC405EP boards
global and callable from C code.
pll_write can be used to dynamically modify the PLB:PCI divider
as it is required for 33/66 MHz pci adapters based on the 405EP.
board_early_init_f() is a good place to do that (check M66EN signal
and call pll_write() when it is required).
Signed-off-by: Matthias Fuchs <matthias.fuchs@esd.eu>
Signed-off-by: Stefan Roese <sr@denx.de>
This patch implements the is_pci_host() function in a similiar way
as it is used on 440 targets.
The former path with CONFIG_PCI_HOST == PCI_HOST_AUTO does not
build on 405EP targets because checking the PCI arbiter is different.
So putting the fixed code into a separate function makes the code
more readable.
Also using is_pci_host() on 405 brings 405 and 440 PCI code
a little bit closer.
In preparation for an upcoming 405EP based PMC module I made this
function weak so that it can be overwritten from board specific code.
Signed-off-by: Matthias Fuchs <matthias.fuchs@esd.eu>
Signed-off-by: Stefan Roese <sr@denx.de>
This patch fixes a debug compilation error for PPC4xx platforms, all
other architectures are not affected by this change. The 'handler'
pointer was undefined. The fix is exercised and has effect only if
DEBUG is defined.
Signed-off-by: Alessio Centazzo acpatin@yahoo.com
Signed-off-by: Stefan Roese <sr@denx.de>
This patch fixes printf format string compilation warnings in several
debug statements. It also fixes the dump of DDR controller MQ registers
found on some 44x and 46x platforms. The current register dump code
uses incorrect DCRs to access these registers.
Signed-off-by: Felix Radensky <felix@embedded-sol.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Matthias Ludwig