wdenk | 57b2d80 | 2003-06-27 21:31:46 +0000 | [diff] [blame] | 1 | PowerPC 440 |
wdenk | c609719 | 2002-11-03 00:24:07 +0000 | [diff] [blame] | 2 | |
wdenk | 57b2d80 | 2003-06-27 21:31:46 +0000 | [diff] [blame] | 3 | Last Update: September 11, 2002 |
wdenk | c609719 | 2002-11-03 00:24:07 +0000 | [diff] [blame] | 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 IBM 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 | |
wdenk | c609719 | 2002-11-03 00:24:07 +0000 | [diff] [blame] | 200 | Regards, |
| 201 | --Scott |
| 202 | <smcnutt@artesyncp.com> |