mirror of
https://github.com/brain-hackers/u-boot-brain
synced 2024-08-23 10:28:51 +09:00
![Peter Tyser](/assets/img/avatar_default.png)
The individual i2c commands imd, imm, inm, imw, icrc32, iprobe, iloop, and isdram are no longer available so all references to them have been updated to the new form of "i2c <cmd>". Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
204 lines
8.5 KiB
Plaintext
204 lines
8.5 KiB
Plaintext
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>
|