]>
Commit | Line | Data |
---|---|---|
8bde7f77 | 1 | PowerPC 440 |
c609719b | 2 | |
8bde7f77 | 3 | Last Update: September 11, 2002 |
c609719b WD |
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 | ||
0c8721a4 | 15 | All testing was performed using the AMCC Ebony board using both |
c609719b WD |
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 | |
466fff1a SR |
149 | call the routine pci_pre_init(). This routine is implemented by |
150 | board-specific code & is where the board can over-ride/extend the | |
151 | default pci_controller structure settings and exspecially provide | |
152 | a routine to map the PCI interrupts and do other pre-initialization | |
153 | tasks. If pci_pre_init() returns a value of zero, PCI initialization | |
154 | is aborted; otherwise the controller structure is registered and | |
155 | initialization continues. | |
c609719b WD |
156 | |
157 | The default 440GP PCI target configuration is minimal -- it assumes that | |
158 | the strapping registers are set as necessary. Since the strapping bits | |
159 | provide very limited flexibility, you may want to customize the boards | |
160 | target configuration. If CFG_PCI_TARGET_INIT is defined, the cpu-specific | |
161 | code will call the routine pci_target_init() which you must implement | |
162 | in your board-specific code. | |
163 | ||
164 | Target initialization is completed by the cpu-specific code by | |
165 | initializing the subsystem id and subsystem vendor id, and then ensuring | |
166 | that the 'enable host configuration' bit in the PCIX0_BRDGOPT2 is set. | |
167 | ||
168 | The default PCI master initialization maps in 256 MB of pci memory | |
169 | starting at PCI address CFG_PCI_MEMBASE. To customize this, define | |
170 | PCI_MASTER_INIT. This will call the routine pci_master_init() in your | |
171 | board-specific code rather than performing the default master | |
172 | initialization. | |
173 | ||
174 | The decision to perform PCI host configuration must often be determined | |
175 | at run time. The ppc440 port differs from most other implementations in | |
176 | that it requires the board to determine its host configuration at run | |
177 | time rather than by using compile-time flags. This shouldn't create a | |
178 | large impact on the board-specific code since the board only needs to | |
179 | implement a single routine that returns a zero or non-zero value: | |
180 | is_pci_host(). | |
181 | ||
182 | Justification for this becomes clear when considering systems running | |
183 | in a cPCI environment: | |
184 | ||
185 | 1. Arbiter strapping: Many cPCI boards provide an external arbiter (often | |
186 | part of the PCI-to-PCI bridge). Even though the arbiter is external (the | |
187 | arbiter strapping is negated), the CPU may still be required to perform | |
188 | local PCI bus configuration. | |
189 | ||
190 | 2. Host only: PPMC boards must sample the MONARCH# signal at run-time. | |
191 | Depending on the configuration of the carrier boar, the PPMC board must | |
192 | determine if it should configure the PCI bus at run-time. And in most | |
193 | cases, access to the MONARCH# signal is board-specific (e.g. via | |
194 | board-specific FPGA registers, etc). | |
195 | ||
196 | In any event, the is_pci_host() routine gives each board the opportunity | |
197 | to decide at run-time. If your board is always configured a certain way, | |
198 | then just hardcode a return of 1 or 0 as appropriate. | |
199 | ||
200 | ||
c609719b WD |
201 | Regards, |
202 | --Scott | |
203 | <[email protected]> |