From c609719b8d1b2dca590e0ed499016d041203e403 Mon Sep 17 00:00:00 2001 From: wdenk Date: Sun, 3 Nov 2002 00:24:07 +0000 Subject: Initial revision --- doc/README.ppc440 | 204 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 204 insertions(+) create mode 100644 doc/README.ppc440 (limited to 'doc/README.ppc440') diff --git a/doc/README.ppc440 b/doc/README.ppc440 new file mode 100644 index 000000000..acb0c6f8e --- /dev/null +++ b/doc/README.ppc440 @@ -0,0 +1,204 @@ + 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 IBM 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 ;-) + +CFG_SDRAM_BASE - The virtual address where SDRAM is mapped (always 0) + +CFG_FLASH_BASE - The virtual address where FLASH is mapped. + +CFG_PCI_MEMBASE - The virtual address where PCI-bus memory is mapped. + This mapping provides access to PCI-bus memory. + +CFG_PERIPHERAL_BASE - The virtual address where the 440 memory-mapped + peripherals are mapped. (e.g. -- UART registers, IIC registers, etc). + +CFG_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. + +CFG_PCI_BASE - The virtual address where the 440 PCI-x bridge config + registers are mapped. + +CFG_PCI_TARGBASE - The PCI address that is mapped to the virtual address + defined by CFG_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 CFG_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 iprobe 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 +CFG_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 iprobe command. + +For example, to prevent probing address 0x69, define the macro as +follows: + +#define CFG_I2C_NOPROBES {0x69} + +Similarly, to prevent probing addresses 0x69 and 0x70, define the +macro a: + +#define CFG_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 CFG_PCI_TARGBASE. After the +pci_controller structure is initialized, the cpu-specific code will +call the routine pci_pre_init() if the CFG_PCI_PRE_INIT flag is +defined. This routine is implemented by board-specific code & is where +the board can over-ride/extend the default pci_controller structure +settings 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 CFG_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 CFG_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 + + -- cgit v1.2.3