diff options
Diffstat (limited to 'qemu/roms/u-boot/doc/README.ppc440')
| -rw-r--r-- | qemu/roms/u-boot/doc/README.ppc440 | 197 |
1 files changed, 0 insertions, 197 deletions
diff --git a/qemu/roms/u-boot/doc/README.ppc440 b/qemu/roms/u-boot/doc/README.ppc440 deleted file mode 100644 index dd8ccaad0..000000000 --- a/qemu/roms/u-boot/doc/README.ppc440 +++ /dev/null @@ -1,197 +0,0 @@ - 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. - - -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> |