doc/README.ppc440

   1                            PowerPC 440
   2
   3                     Last Update: September 11, 2002
   4 =======================================================================
   5
   6
   7 OVERVIEW
   8 ============
   9
  10 Support for the ppc440 is contained in the cpu/ppc44x directory
  11 and enabled via the CONFIG_440 flag. It is largely based on the
  12 405gp code. A sample board support implementation is contained
  13 in the board/ebony directory.
  14
  15 All testing was performed using the AMCC Ebony board using both
  16 Rev B and Rev C silicon. However, since the Rev B. silicon has
  17 extensive errata, support for Rev B. is minimal (it boots, and
  18 features such as i2c, pci, tftpboot, etc. seem to work ok).
  19 The expectation is that all new board designs will be using
  20 Rev C or later parts -- if not, you may be in for a rough ride ;-)
  21
  22 The ppc440 port does a fair job of keeping "board-specific" code
  23 out of the "cpu-specific" source. The goal of course was to
  24 provide mechanisms for each board to customize without having
  25 to clutter the cpu-specific source with a lot of ifdefs. Most
  26 of these mechanisms are described in the following sections.
  27
  28
  29 MEMORY MANAGEMENT
  30 =================
  31
  32 The ppc440 doesn't run in "real mode". The MMU must be active
  33 at all times. Additionally, the 440 implements a 36-bit physical
  34 memory space that gets mapped into the PowerPC 32-bit virtual
  35 address space. So things like memory-mapped peripherals, etc must
  36 all be mapped in. Once this is done, the 32-bit virtual address
  37 space is then viewed as though it were physical memory.
  38
  39 However, this means that memory, peripherals, etc can be configured
  40 to appear (mostly) anywhere in the virtual address space. Each board
  41 must define its own mappings using the tlbtab (see board/ebony/init.S).
  42 The actual TLB setup is performed by the cpu-specific code.
  43
  44 Although each board is free to define its own mappings, there are
  45 several definitions to be aware of. These definitions may be used in
  46 the cpu-specific code (vs. board-specific code), so you should
  47 at least review these before deciding to make any changes ... it
  48 will probably save you some headaches ;-)
  49
  50 CFG_SDRAM_BASE - The virtual address where SDRAM is mapped (always 0)
  51
  52 CFG_FLASH_BASE - The virtual address where FLASH is mapped.
  53
  54 CFG_PCI_MEMBASE - The virtual address where PCI-bus memory is mapped.
  55     This mapping provides access to PCI-bus memory.
  56
  57 CFG_PERIPHERAL_BASE - The virtual address where the 440 memory-mapped
  58     peripherals are mapped. (e.g. -- UART registers, IIC registers, etc).
  59
  60 CFG_ISRAM_BASE - The virtual address where the 440 internal SRAM is
  61     mapped. The internal SRAM is equivalent to 405gp OCM and is used
  62     for the initial stack.
  63
  64 CFG_PCI_BASE - The virtual address where the 440 PCI-x bridge config
  65     registers are mapped.
  66
  67 CFG_PCI_TARGBASE - The PCI address that is mapped to the virtual address
  68     defined by CFG_PCI_MEMBASE.
  69
  70
  71 UART / SERIAL
  72 =================
  73
  74 The UART port works fine when an external serial clock is provided
  75 (like the one on the Ebony board) and when using internal clocking.
  76 This is controlled with the CFG_EXT_SERIAL_CLOCK flag. When using
  77 internal clocking, the "ideal baud rate" settings in the 440GP
  78 user manual are automatically calculated.
  79
  80 CONFIG_SERIAL_SOFTWARE_FIFO enables interrupt-driven serial operation.
  81 But the last time I checked, interrupts were initialized after the
  82 serial port causing the interrupt handler to be removed from the
  83 handler table. This will probably be fixed soon ... or fix it
  84 yourself and submit a patch :-)
  85
  86
  87 I2C
  88 =================
  89
  90 The i2c utilities have been tested on both Rev B. and Rev C. and
  91 look good. The iprobe command implementation has been updated to
  92 allow for 'skipped' addresses. Some i2c slaves are write only and
  93 cause problems when a probe (read) is performed (for example the
  94 CDCV850 clock controller at address 0x69 on the ebony board).
  95
  96 To prevent probing certain addresses you can define the
  97 CFG_I2C_NOPROBES macro in your board-specific header file. When
  98 defined, all specified addresses are skipped during a probe.
  99 The addresses that are skipped will be displayed in the output
 100 of the iprobe command.
 101
 102 For example, to prevent probing address 0x69, define the macro as
 103 follows:
 104
 105 #define CFG_I2C_NOPROBES {0x69}
 106
 107 Similarly, to prevent probing addresses 0x69 and 0x70, define the
 108 macro a:
 109
 110 #define CFG_I2C_NOPROBES {0x69, 0x70}
 111
 112
 113 DDR SDRAM CONTROLLER
 114 ====================
 115
 116 SDRAM controller intialization using Serial Presence Detect (SPD) is
 117 now supported (thanks Jun). It is enabled by defining CONFIG_SPD_EEPROM.
 118 The i2c eeprom addresses are controlled by the SPD_EEPROM_ADDRESS macro.
 119
 120 NOTE: The SPD_EEPROM_ADDRESS macro is defined differently than for other
 121 processors. Traditionally, it defined a single address. For the 440 it
 122 defines an array of addresses to support multiple banks. Address order
 123 is significant: the addresses are used in order to program the BankN
 124 registers. For example, two banks with i2c addresses of 0x53 (bank 0)
 125 and 0x52 (bank 1) would be defined as follows:
 126
 127 #define SPD_EEPROM_ADDRESS {0x53,0x52}
 128
 129
 130 PCI-X BRIDGE
 131 ====================
 132
 133 PCI is an area that requires lots of flexibility since every board has
 134 its own set of constraints and configuration. This section describes the
 135 440 implementation.
 136
 137 CPC0_STRP1[PISE] -- if the PISE strap bit is not asserted, PCI init
 138 is aborted and an indication is printed. This is NOT considered an
 139 error -- only an indication that PCI shouldn't be initialized. This
 140 gives you a chance to edit the i2c bootstrap eeproms using the i2c
 141 utilities once you get to the U-Boot command prompt. NOTE: the default
 142 440 bootstrap options (not using i2c eeprom) negates this bit.
 143
 144 The cpu-specific code sets up a default pci_controller structure
 145 that maps in a single PCI I/O space and PCI memory space. The I/O
 146 space begins at PCI I/O address 0 and the PCI memory space is
 147 256 MB starting at PCI address CFG_PCI_TARGBASE. After the
 148 pci_controller structure is initialized, the cpu-specific code will
 149 call the routine pci_pre_init() if the CFG_PCI_PRE_INIT flag is
 150 defined. This routine is implemented by board-specific code & is where
 151 the board can over-ride/extend the default pci_controller structure
 152 settings and do other pre-initialization tasks. If pci_pre_init()
 153 returns a value of zero, PCI initialization is aborted; otherwise the
 154 controller structure is registered and initialization continues.
 155
 156 The default 440GP PCI target configuration is minimal -- it assumes that
 157 the strapping registers are set as necessary. Since the strapping bits
 158 provide very limited flexibility, you may want to customize the boards
 159 target configuration. If CFG_PCI_TARGET_INIT is defined, the cpu-specific
 160 code will call the routine pci_target_init() which you must implement
 161 in your board-specific code.
 162
 163 Target initialization is completed by the cpu-specific code by
 164 initializing the subsystem id and subsystem vendor id, and then ensuring
 165 that the 'enable host configuration' bit in the PCIX0_BRDGOPT2 is set.
 166
 167 The default PCI master initialization maps in 256 MB of pci memory
 168 starting at PCI address CFG_PCI_MEMBASE. To customize this, define
 169 PCI_MASTER_INIT. This will call the routine pci_master_init() in your
 170 board-specific code rather than performing the default master
 171 initialization.
 172
 173 The decision to perform PCI host configuration must often be determined
 174 at run time. The ppc440 port differs from most other implementations in
 175 that it requires the board to determine its host configuration at run
 176 time rather than by using compile-time flags. This shouldn't create a
 177 large impact on the board-specific code since the board only needs to
 178 implement a single routine that returns a zero or non-zero value:
 179 is_pci_host().
 180
 181 Justification for this becomes clear when considering systems running
 182 in a cPCI environment:
 183
 184 1. Arbiter strapping: Many cPCI boards provide an external arbiter (often
 185 part of the PCI-to-PCI bridge). Even though the arbiter is external (the
 186 arbiter strapping is negated), the CPU may still be required to perform
 187 local PCI bus configuration.
 188
 189 2. Host only: PPMC boards must sample the MONARCH# signal at run-time.
 190 Depending on the configuration of the carrier boar, the PPMC board must
 191 determine if it should configure the PCI bus at run-time. And in most
 192 cases, access to the MONARCH# signal is board-specific (e.g. via
 193 board-specific FPGA registers, etc).
 194
 195 In any event, the is_pci_host() routine gives each board the opportunity
 196 to decide at run-time. If your board is always configured a certain way,
 197 then just hardcode a return of 1 or 0 as appropriate.
 198
 199
 200 Regards,
 201 --Scott
 202 <smcnutt@artesyncp.com>