doc/README.ppc440 - uboot/armada - Git at Google

 			   PowerPC 440

 		    Last Update: September 11, 2002
 =======================================================================


 OVERVIEW
 ============

 Support for the ppc440 is contained in the cpu/ppc44x directory
 and enabled via the CONFIG_440 flag. It is largely based on the
 405gp code. A sample board support implementation is contained
 in the board/ebony directory.

 All testing was performed using the AMCC Ebony board using both
 Rev B and Rev C silicon. However, since the Rev B. silicon has
 extensive errata, support for Rev B. is minimal (it boots, and
 features such as i2c, pci, tftpboot, etc. seem to work ok).
 The expectation is that all new board designs will be using
 Rev C or later parts -- if not, you may be in for a rough ride ;-)

 The ppc440 port does a fair job of keeping "board-specific" code
 out of the "cpu-specific" source. The goal of course was to
 provide mechanisms for each board to customize without having
 to clutter the cpu-specific source with a lot of ifdefs. Most
 of these mechanisms are described in the following sections.


 MEMORY MANAGEMENT
 =================

 The ppc440 doesn't run in "real mode". The MMU must be active
 at all times. Additionally, the 440 implements a 36-bit physical
 memory space that gets mapped into the PowerPC 32-bit virtual
 address space. So things like memory-mapped peripherals, etc must
 all be mapped in. Once this is done, the 32-bit virtual address
 space is then viewed as though it were physical memory.

 However, this means that memory, peripherals, etc can be configured
 to appear (mostly) anywhere in the virtual address space. Each board
 must define its own mappings using the tlbtab (see board/ebony/init.S).
 The actual TLB setup is performed by the cpu-specific code.

 Although each board is free to define its own mappings, there are
 several definitions to be aware of. These definitions may be used in
 the cpu-specific code (vs. board-specific code), so you should
 at least review these before deciding to make any changes ... it
 will probably save you some headaches ;-)

 CONFIG_SYS_SDRAM_BASE - The virtual address where SDRAM is mapped (always 0)

 CONFIG_SYS_FLASH_BASE - The virtual address where FLASH is mapped.

 CONFIG_SYS_PCI_MEMBASE - The virtual address where PCI-bus memory is mapped.
     This mapping provides access to PCI-bus memory.

 CONFIG_SYS_PERIPHERAL_BASE - The virtual address where the 440 memory-mapped
     peripherals are mapped. (e.g. -- UART registers, IIC registers, etc).

 CONFIG_SYS_ISRAM_BASE - The virtual address where the 440 internal SRAM is
     mapped. The internal SRAM is equivalent to 405gp OCM and is used
     for the initial stack.

 CONFIG_SYS_PCI_BASE - The virtual address where the 440 PCI-x bridge config
     registers are mapped.

 CONFIG_SYS_PCI_TARGBASE - The PCI address that is mapped to the virtual address
     defined by CONFIG_SYS_PCI_MEMBASE.


 UART / SERIAL
 =================

 The UART port works fine when an external serial clock is provided
 (like the one on the Ebony board) and when using internal clocking.
 This is controlled with the CONFIG_SYS_EXT_SERIAL_CLOCK flag. When using
 internal clocking, the "ideal baud rate" settings in the 440GP
 user manual are automatically calculated.


 I2C
 =================

 The i2c utilities have been tested on both Rev B. and Rev C. and
 look good. The 'i2c probe' command implementation has been updated to
 allow for 'skipped' addresses. Some i2c slaves are write only and
 cause problems when a probe (read) is performed (for example the
 CDCV850 clock controller at address 0x69 on the ebony board).

 To prevent probing certain addresses you can define the
 CONFIG_SYS_I2C_NOPROBES macro in your board-specific header file. When
 defined, all specified addresses are skipped during a probe.
 The addresses that are skipped will be displayed in the output
 of the 'i2c probe' command.

 For example, to prevent probing address 0x69, define the macro as
 follows:

 #define CONFIG_SYS_I2C_NOPROBES {0x69}

 Similarly, to prevent probing addresses 0x69 and 0x70, define the
 macro a:

 #define CONFIG_SYS_I2C_NOPROBES {0x69, 0x70}


 DDR SDRAM CONTROLLER
 ====================

 SDRAM controller intialization using Serial Presence Detect (SPD) is
 now supported (thanks Jun). It is enabled by defining CONFIG_SPD_EEPROM.
 The i2c eeprom addresses are controlled by the SPD_EEPROM_ADDRESS macro.

 NOTE: The SPD_EEPROM_ADDRESS macro is defined differently than for other
 processors. Traditionally, it defined a single address. For the 440 it
 defines an array of addresses to support multiple banks. Address order
 is significant: the addresses are used in order to program the BankN
 registers. For example, two banks with i2c addresses of 0x53 (bank 0)
 and 0x52 (bank 1) would be defined as follows:

 #define SPD_EEPROM_ADDRESS {0x53,0x52}


 PCI-X BRIDGE
 ====================

 PCI is an area that requires lots of flexibility since every board has
 its own set of constraints and configuration. This section describes the
 440 implementation.

 CPC0_STRP1[PISE] -- if the PISE strap bit is not asserted, PCI init
 is aborted and an indication is printed. This is NOT considered an
 error -- only an indication that PCI shouldn't be initialized. This
 gives you a chance to edit the i2c bootstrap eeproms using the i2c
 utilities once you get to the U-Boot command prompt. NOTE: the default
 440 bootstrap options (not using i2c eeprom) negates this bit.

 The cpu-specific code sets up a default pci_controller structure
 that maps in a single PCI I/O space and PCI memory space. The I/O
 space begins at PCI I/O address 0 and the PCI memory space is
 256 MB starting at PCI address CONFIG_SYS_PCI_TARGBASE. After the
 pci_controller structure is initialized, the cpu-specific code will
 call the routine pci_pre_init(). This routine is implemented by
 board-specific code & is where the board can over-ride/extend the
 default pci_controller structure settings and exspecially provide
 a routine to map the PCI interrupts and do other pre-initialization
 tasks. If pci_pre_init() returns a value of zero, PCI initialization
 is aborted; otherwise the controller structure is registered and
 initialization continues.

 The default 440GP PCI target configuration is minimal -- it assumes that
 the strapping registers are set as necessary. Since the strapping bits
 provide very limited flexibility, you may want to customize the boards
 target configuration. If CONFIG_SYS_PCI_TARGET_INIT is defined, the cpu-specific
 code will call the routine pci_target_init() which you must implement
 in your board-specific code.

 Target initialization is completed by the cpu-specific code by
 initializing the subsystem id and subsystem vendor id, and then ensuring
 that the 'enable host configuration' bit in the PCIX0_BRDGOPT2 is set.

 The default PCI master initialization maps in 256 MB of pci memory
 starting at PCI address CONFIG_SYS_PCI_MEMBASE. To customize this, define
 PCI_MASTER_INIT. This will call the routine pci_master_init() in your
 board-specific code rather than performing the default master
 initialization.

 The decision to perform PCI host configuration must often be determined
 at run time. The ppc440 port differs from most other implementations in
 that it requires the board to determine its host configuration at run
 time rather than by using compile-time flags. This shouldn't create a
 large impact on the board-specific code since the board only needs to
 implement a single routine that returns a zero or non-zero value:
 is_pci_host().

 Justification for this becomes clear when considering systems running
 in a cPCI environment:

 1. Arbiter strapping: Many cPCI boards provide an external arbiter (often
 part of the PCI-to-PCI bridge). Even though the arbiter is external (the
 arbiter strapping is negated), the CPU may still be required to perform
 local PCI bus configuration.

 2. Host only: PPMC boards must sample the MONARCH# signal at run-time.
 Depending on the configuration of the carrier boar, the PPMC board must
 determine if it should configure the PCI bus at run-time. And in most
 cases, access to the MONARCH# signal is board-specific (e.g. via
 board-specific FPGA registers, etc).

 In any event, the is_pci_host() routine gives each board the opportunity
 to decide at run-time. If your board is always configured a certain way,
 then just hardcode a return of 1 or 0 as appropriate.


 Regards,
 --Scott
 <smcnutt@artesyncp.com>
	PowerPC 440

	Last Update: September 11, 2002
	=======================================================================


	OVERVIEW
	============

	Support for the ppc440 is contained in the cpu/ppc44x directory
	and enabled via the CONFIG_440 flag. It is largely based on the
	405gp code. A sample board support implementation is contained
	in the board/ebony directory.

	All testing was performed using the AMCC Ebony board using both
	Rev B and Rev C silicon. However, since the Rev B. silicon has
	extensive errata, support for Rev B. is minimal (it boots, and
	features such as i2c, pci, tftpboot, etc. seem to work ok).
	The expectation is that all new board designs will be using
	Rev C or later parts -- if not, you may be in for a rough ride ;-)

	The ppc440 port does a fair job of keeping "board-specific" code
	out of the "cpu-specific" source. The goal of course was to
	provide mechanisms for each board to customize without having
	to clutter the cpu-specific source with a lot of ifdefs. Most
	of these mechanisms are described in the following sections.


	MEMORY MANAGEMENT
	=================

	The ppc440 doesn't run in "real mode". The MMU must be active
	at all times. Additionally, the 440 implements a 36-bit physical
	memory space that gets mapped into the PowerPC 32-bit virtual
	address space. So things like memory-mapped peripherals, etc must
	all be mapped in. Once this is done, the 32-bit virtual address
	space is then viewed as though it were physical memory.

	However, this means that memory, peripherals, etc can be configured
	to appear (mostly) anywhere in the virtual address space. Each board
	must define its own mappings using the tlbtab (see board/ebony/init.S).
	The actual TLB setup is performed by the cpu-specific code.

	Although each board is free to define its own mappings, there are
	several definitions to be aware of. These definitions may be used in
	the cpu-specific code (vs. board-specific code), so you should
	at least review these before deciding to make any changes ... it
	will probably save you some headaches ;-)

	CONFIG_SYS_SDRAM_BASE - The virtual address where SDRAM is mapped (always 0)

	CONFIG_SYS_FLASH_BASE - The virtual address where FLASH is mapped.

	CONFIG_SYS_PCI_MEMBASE - The virtual address where PCI-bus memory is mapped.
	This mapping provides access to PCI-bus memory.

	CONFIG_SYS_PERIPHERAL_BASE - The virtual address where the 440 memory-mapped
	peripherals are mapped. (e.g. -- UART registers, IIC registers, etc).

	CONFIG_SYS_ISRAM_BASE - The virtual address where the 440 internal SRAM is
	mapped. The internal SRAM is equivalent to 405gp OCM and is used
	for the initial stack.

	CONFIG_SYS_PCI_BASE - The virtual address where the 440 PCI-x bridge config
	registers are mapped.

	CONFIG_SYS_PCI_TARGBASE - The PCI address that is mapped to the virtual address
	defined by CONFIG_SYS_PCI_MEMBASE.


	UART / SERIAL
	=================

	The UART port works fine when an external serial clock is provided
	(like the one on the Ebony board) and when using internal clocking.
	This is controlled with the CONFIG_SYS_EXT_SERIAL_CLOCK flag. When using
	internal clocking, the "ideal baud rate" settings in the 440GP
	user manual are automatically calculated.


	I2C
	=================

	The i2c utilities have been tested on both Rev B. and Rev C. and
	look good. The 'i2c probe' command implementation has been updated to
	allow for 'skipped' addresses. Some i2c slaves are write only and
	cause problems when a probe (read) is performed (for example the
	CDCV850 clock controller at address 0x69 on the ebony board).

	To prevent probing certain addresses you can define the
	CONFIG_SYS_I2C_NOPROBES macro in your board-specific header file. When
	defined, all specified addresses are skipped during a probe.
	The addresses that are skipped will be displayed in the output
	of the 'i2c probe' command.

	For example, to prevent probing address 0x69, define the macro as
	follows:

	#define CONFIG_SYS_I2C_NOPROBES {0x69}

	Similarly, to prevent probing addresses 0x69 and 0x70, define the
	macro a:

	#define CONFIG_SYS_I2C_NOPROBES {0x69, 0x70}


	DDR SDRAM CONTROLLER
	====================

	SDRAM controller intialization using Serial Presence Detect (SPD) is
	now supported (thanks Jun). It is enabled by defining CONFIG_SPD_EEPROM.
	The i2c eeprom addresses are controlled by the SPD_EEPROM_ADDRESS macro.

	NOTE: The SPD_EEPROM_ADDRESS macro is defined differently than for other
	processors. Traditionally, it defined a single address. For the 440 it
	defines an array of addresses to support multiple banks. Address order
	is significant: the addresses are used in order to program the BankN
	registers. For example, two banks with i2c addresses of 0x53 (bank 0)
	and 0x52 (bank 1) would be defined as follows:

	#define SPD_EEPROM_ADDRESS {0x53,0x52}


	PCI-X BRIDGE
	====================

	PCI is an area that requires lots of flexibility since every board has
	its own set of constraints and configuration. This section describes the
	440 implementation.

	CPC0_STRP1[PISE] -- if the PISE strap bit is not asserted, PCI init
	is aborted and an indication is printed. This is NOT considered an
	error -- only an indication that PCI shouldn't be initialized. This
	gives you a chance to edit the i2c bootstrap eeproms using the i2c
	utilities once you get to the U-Boot command prompt. NOTE: the default
	440 bootstrap options (not using i2c eeprom) negates this bit.

	The cpu-specific code sets up a default pci_controller structure
	that maps in a single PCI I/O space and PCI memory space. The I/O
	space begins at PCI I/O address 0 and the PCI memory space is
	256 MB starting at PCI address CONFIG_SYS_PCI_TARGBASE. After the
	pci_controller structure is initialized, the cpu-specific code will
	call the routine pci_pre_init(). This routine is implemented by
	board-specific code & is where the board can over-ride/extend the
	default pci_controller structure settings and exspecially provide
	a routine to map the PCI interrupts and do other pre-initialization
	tasks. If pci_pre_init() returns a value of zero, PCI initialization
	is aborted; otherwise the controller structure is registered and
	initialization continues.

	The default 440GP PCI target configuration is minimal -- it assumes that
	the strapping registers are set as necessary. Since the strapping bits
	provide very limited flexibility, you may want to customize the boards
	target configuration. If CONFIG_SYS_PCI_TARGET_INIT is defined, the cpu-specific
	code will call the routine pci_target_init() which you must implement
	in your board-specific code.

	Target initialization is completed by the cpu-specific code by
	initializing the subsystem id and subsystem vendor id, and then ensuring
	that the 'enable host configuration' bit in the PCIX0_BRDGOPT2 is set.

	The default PCI master initialization maps in 256 MB of pci memory
	starting at PCI address CONFIG_SYS_PCI_MEMBASE. To customize this, define
	PCI_MASTER_INIT. This will call the routine pci_master_init() in your
	board-specific code rather than performing the default master
	initialization.

	The decision to perform PCI host configuration must often be determined
	at run time. The ppc440 port differs from most other implementations in
	that it requires the board to determine its host configuration at run
	time rather than by using compile-time flags. This shouldn't create a
	large impact on the board-specific code since the board only needs to
	implement a single routine that returns a zero or non-zero value:
	is_pci_host().

	Justification for this becomes clear when considering systems running
	in a cPCI environment:

	1. Arbiter strapping: Many cPCI boards provide an external arbiter (often
	part of the PCI-to-PCI bridge). Even though the arbiter is external (the
	arbiter strapping is negated), the CPU may still be required to perform
	local PCI bus configuration.

	2. Host only: PPMC boards must sample the MONARCH# signal at run-time.
	Depending on the configuration of the carrier boar, the PPMC board must
	determine if it should configure the PCI bus at run-time. And in most
	cases, access to the MONARCH# signal is board-specific (e.g. via
	board-specific FPGA registers, etc).

	In any event, the is_pci_host() routine gives each board the opportunity
	to decide at run-time. If your board is always configured a certain way,
	then just hardcode a return of 1 or 0 as appropriate.


	Regards,
	--Scott
	<smcnutt@artesyncp.com>