203 lines
8.5 KiB
Text
203 lines
8.5 KiB
Text
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.
|
|
|
|
CONFIG_SERIAL_SOFTWARE_FIFO enables interrupt-driven serial operation.
|
|
But the last time I checked, interrupts were initialized after the
|
|
serial port causing the interrupt handler to be removed from the
|
|
handler table. This will probably be fixed soon ... or fix it
|
|
yourself and submit a patch :-)
|
|
|
|
|
|
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>
|