README.ppc440 8.19 KB
Newer Older
wdenk's avatar
wdenk committed
			   PowerPC 440
wdenk's avatar
wdenk committed

wdenk's avatar
wdenk committed
		    Last Update: September 11, 2002
wdenk's avatar
wdenk committed
4 5 6 7 8 9 10 11 12 13 14


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
wdenk's avatar
wdenk committed
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
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.


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)
wdenk's avatar
wdenk committed

CONFIG_SYS_FLASH_BASE - The virtual address where FLASH is mapped.
wdenk's avatar
wdenk committed

CONFIG_SYS_PCI_MEMBASE - The virtual address where PCI-bus memory is mapped.
wdenk's avatar
wdenk committed
55 56
    This mapping provides access to PCI-bus memory.

CONFIG_SYS_PERIPHERAL_BASE - The virtual address where the 440 memory-mapped
wdenk's avatar
wdenk committed
58 59
    peripherals are mapped. (e.g. -- UART registers, IIC registers, etc).

CONFIG_SYS_ISRAM_BASE - The virtual address where the 440 internal SRAM is
wdenk's avatar
wdenk committed
61 62 63
    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
wdenk's avatar
wdenk committed
65 66
    registers are mapped.

67 68
CONFIG_SYS_PCI_TARGBASE - The PCI address that is mapped to the virtual address
    defined by CONFIG_SYS_PCI_MEMBASE.
wdenk's avatar
wdenk committed
69 70 71 72 73 74 75


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
wdenk's avatar
wdenk committed
77 78 79 80 81 82 83 84
internal clocking, the "ideal baud rate" settings in the 440GP
user manual are automatically calculated.


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
wdenk's avatar
wdenk committed
86 87 88 89 90
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
wdenk's avatar
wdenk committed
92 93
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.
wdenk's avatar
wdenk committed
95 96 97 98

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

#define CONFIG_SYS_I2C_NOPROBES {0x69}
wdenk's avatar
wdenk committed
100 101 102 103

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

#define CONFIG_SYS_I2C_NOPROBES {0x69, 0x70}
wdenk's avatar
wdenk committed
105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140


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 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
wdenk's avatar
wdenk committed
pci_controller structure is initialized, the cpu-specific code will
143 144 145 146 147 148 149
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.
wdenk's avatar
wdenk committed
150 151 152 153

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
wdenk's avatar
wdenk committed
155 156 157 158 159 160 161 162
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
wdenk's avatar
wdenk committed
164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197
PCI_MASTER_INIT. This will call the routine pci_master_init() in your
board-specific code rather than performing the default master

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:

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.