diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/README.JFFS2 | 68 | ||||
| -rw-r--r-- | doc/README.Modem | 73 | ||||
| -rw-r--r-- | doc/README.commands | 99 | ||||
| -rw-r--r-- | doc/README.ebony | 138 | ||||
| -rw-r--r-- | doc/README.ppc440 | 204 |
5 files changed, 582 insertions, 0 deletions
diff --git a/doc/README.JFFS2 b/doc/README.JFFS2 new file mode 100644 index 0000000..0d39c46 --- /dev/null +++ b/doc/README.JFFS2 @@ -0,0 +1,68 @@ +JFFS2 options and usage. +----------------------- + +JFFS2 in U-Boot is a read only implementation of the file system in +Linux with the same name. To use JFFS2 define CFG_CMD_JFFS2. + +The module adds three new commands. +fsload - load binary file from a file system image +fsinfo - print information about file systems +ls - list files in a directory + + +There is two ways for JFFS2 to find the disk. The default way uses +the flash_info structure to find the start of a JFFS2 disk (called +partition in the code) and you can change where the partition is with +two defines. + +CFG_JFFS2_FIRST_BANK + defined the first flash bank to use + +CFG_JFFS2_FIRST_SECTOR + defines the first sector to use + + +The second way is to define CFG_JFFS_CUSTOM_PART and implement the +jffs2_part_info(int part_num) function in your board specific files. +In this mode CFG_JFFS2_FIRST_BANK and CFG_JFFS2_FIRST_SECTOR is not +used. + +The input is a partition number starting with 0. +Return a pointer to struct part_info or NULL for error; + +Ex jffs2_part_info() for one partition. +--- +#if defined CFG_JFFS_CUSTOM_PART +#include <jffs2/jffs2.h> + +static struct part_info part; + +struct part_info* +jffs2_part_info(int part_num) +{ + if(part_num==0){ + if(part.usr_priv==(void*)1) + return ∂ + + memset(&part, 0, sizeof(part)); + part.offset=(char*)0xFF800000; + part.size=1024*1024*8; + + /* Mark the struct as ready */ + part.usr_priv=(void*)1; + + return ∂ + } + return 0; +} +#endif +--- + +TODO. + + Add a new command so it's actually possible to change + partition. + + Remove the assumption that JFFS can dereference a pointer + into the disk. The current code do not work with memory holes + or hardware with a sliding window (PCMCIA). diff --git a/doc/README.Modem b/doc/README.Modem new file mode 100644 index 0000000..a3ba7b7 --- /dev/null +++ b/doc/README.Modem @@ -0,0 +1,73 @@ +How to configure modem support in U-Boot : + +1. Define modem initialization strings: +--------------------------------------- + +The modem initialization strings have following format: + + mdm_init1=<AT-command> + mdm_init2=<AT-command> + ... + +Turning off modem verbose responses with ATV0 or ATQ1 is not allowed; +U-Boot analyzes only verbose (not numeric) result codes. Modem local +command echo can be turned off (ATE0). + +2. RTS/CTS hardware flow control: +--------------------------------- + +You may wish to enable RTS/CTS hardware flow control, if the board's +UART driver supports it (see CONFIG_HWFLOW compile-time flag in +config/<board>.h). This is controlled by the 'mdm_flow_control' +environment variable: + + 'mdm_flow_control=rts/cts' - to enable RTS/CTS flow control. + 'mdm_flow_control=none ' - to disable. + + +The following are the examples using a Rockwell OEM modem +configuration: + +SAMSUNG # setenv mdm_init1 ATZ - reset the modem to + the factory defaults. +SAMSUNG # setenv mdm_init2 ATS0=1 - set modem into + answer mode. +SAMSUNG # setenv mdm_flow_control rts/cts - enable serial port + flow control +SAMSUNG # saveenv + +The example above initializes modem into answer mode to wait for the +incoming call. RTS/CTS flow control is enabled for the serial port. +(The RTS/CTS flow control is enabled by default on the modem). + + +SAMSUNG # setenv mdm_init1 ATZ +SAMSUNG # setenv mdm_init2 ATS39=0+IFC=0,0 - disable modem + RTS/CTS flow control +SAMSUNG # setenv mdm_init3 ATDT1643973 - dial out the number +SAMSUNG # setenv mdm_flow_control none +SAMSUNG # saveenv + +The example above initializes modem to dial-up connection on the +number 1643973. Flow control is disabled. + +Note that flow control must be turned both off or both on for the +board serial port and for the modem. + + +If the connection was set up successfully, the U-Boot prompt appears +on the terminal console. If not (U-Boot modem was configured for +originating the call and connection was not established) - the board +should be reset for another dial-up try. + + +Note on the SMDK2400 board: +--------------------------- + +Since the board serial ports does not have DTR signal wired, modem +should be told to ignore port DTR setting prior to connection to the +SMDK board, and this setting should be stored in modem NVRAM. For the +Rockwell OEM modem this can to be done with the following command: + +AT&D0&W + diff --git a/doc/README.commands b/doc/README.commands new file mode 100644 index 0000000..576186e --- /dev/null +++ b/doc/README.commands @@ -0,0 +1,99 @@ +# +# The commands in this table are sorted alphabetically by the +# command name and in descending order by the command name string +# length. This is to prevent conflicts in command name parsing. +# Please ensure that new commands are added according to that rule. +# See $(TOPDIR)/common/command.c +# +######################## +# +# command length +# +######################## +askenv 8 +as 2 +autoscr 5 +base 2 +bdinfo 2 +bootelf 7 +bootm 5 +bootp 5 +bootvx 6 +bootd 4 +break 2 +brginfo 3 +carinfo 3 +chpart 6 +cmp 3 +coninfo 5 +continue 4 +cp 2 +crc32 3 +date 3 +dcache 2 +dhcp 4 +dmainfo 3 +ds 2 +dtt 3 +echo 4 +eeprom 3 +erase 3 +fccinfo 3 +fdcboot 4 +flinfo 3 +fpga 4 +fsinfo 5 +fsload 5 +getdcr 6 # IBM 4XX DCR registers +go 2 +help 1 +i2cinfo 4 +i2c 3 +icache 2 +icinfo 3 +ide 3 +iminfo 3 +iopinfo 3 +irqinfo 3 +kgdb 4 +loadb 5 +loads 5 +loop 4 +ls 2 +mccinfo 3 +md 2 +memcinfo 4 +mii 3 +mm 2 +mtest 5 +muxinfo 3 +mw 2 +next 4 +nm 2 +pciinfo 3 +pinit 4 +printenv 8 +protect 4 +rarpboot 4 +rdump 5 +reginfo 3 +reset 5 +run 3 +saveenv 4 +sccinfo 3 +scsiboot 5 +scsi 4 +siiinfo 3 +sitinfo 3 +siuinfo 3 +setdcr 6 # IBM 4XX DCR registers +setenv 6 +smcinfo 3 +spiinfo 3 +stack 5 +step 4 +tftpboot 4 +usbboot 5 +usb 4 +version 4 +? 1 diff --git a/doc/README.ebony b/doc/README.ebony new file mode 100644 index 0000000..12a0d70 --- /dev/null +++ b/doc/README.ebony @@ -0,0 +1,138 @@ + IBM Ebony Board + + Last Update: September 12, 2002 +======================================================================= + +This file contains some handy info regarding U-Boot and the IBM +Ebony evalutation board. See the README.ppc440 for additional +information. + + +SWITCH SETTINGS & JUMPERS +========================== + +Here's what I've been using successfully. If you feel inclined to +change things ... please read the docs! + +DIPSW U46 U80 +------------------------ +SW 1 off on +SW 2 on on +SW 3 on on +SW 4 off on +SW 5 on off +SW 6 on on +SW 7 on off +SW 8 on off + +J41: strapped +J42: open + +All others are factory default. + + +I2C iprobe +===================== + +The i2c utilities have been tested on both Rev B. and Rev C. and +look good. The CFG_I2C_NOPROBES macro is defined to prevent +probing the CDCV850 clock controller at address 0x69 (since reading +it causes the i2c implementation to misbehave. The output of +iprobe should look like this (assuming you are only using a single +SO-DIMM: + +=> iprobe +Valid chip addresses: 50 53 54 +Excluded chip addresses: 69 + + +GETTING OUT OF I2C TROUBLE +=========================== + +If you're like me ... you may have screwed up your bootstrap serial +eeprom ... or worse, your SPD eeprom when experimenting with the +i2c commands. If so, here are some ideas on how to get out of +trouble: + +Serial bootstrap eeprom corruption: +----------------------------------- +Power down the board and set the following straps: + +J41 - open +J42 - strapped + +This will select the default sys0 and sys1 settings (the serial +eeproms are not used). Then power up the board and fix the serial +eeprom using the imm command. Here are the values I currently +use: + +=> imd 50 0 10 +0000: bf a2 04 01 ae 94 11 00 00 00 00 00 00 00 00 00 ................ + +=> imd 54 0 10 +0000: 8f b3 24 01 4d 14 11 00 00 00 00 00 00 00 00 00 ..$.M........... + +Once you have the eeproms set correctly change the +J41/J42 straps as you desire. + +SPD eeprom corruption: +------------------------ +I've corrupted the SPD eeprom several times ... perhaps too much coffee +and not enough presence of mind ;-). By default, the ebony code uses +the SPD to initialize the DDR SDRAM control registers. So if the SPD +eeprom is corrupted, U-Boot will never get into ram. Here's how I got +out of this situation: + +0. First, _before_ playing with the i2c utilities, do an iprobe, then +use imd to capture the various device contents to a file. Some day +you may be glad you did this ... trust me :-). Otherwise try the +following: + +1. In the include/configs/EBONY.h file find the line that defines +the CONFIG_SPD_EEPROM macro and undefine it. E.g: + +#undef CONFIG_SPD_EEPROM + +This will make the code use default SDRAM control register +settings without using the SPD eeprom. + +2. Rebuild U-Boot + +3. Load the new U-Boot image and reboot ebony. + +4. Repair the SPD eeprom using the imm command. Here's the eeprom +contents that work with the default SO-DIMM that comes with the +ebony board (micron 8VDDT164AG-265A1). Note: these are probably +_not_ the factory settings ... but they work. + +=> imd 53 0 10 80 +0000: 80 08 07 0c 0a 01 40 00 04 75 75 00 80 08 00 01 ......@..uu..... +0010: 0e 04 0c 01 02 20 00 a0 75 00 00 50 3c 50 2d 20 ..... ..u..P<P- +0020: 90 90 50 50 00 00 00 00 00 41 4b 34 32 75 00 00 ..PP.....AK42u.. +0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9c ................ +0040: 2c 00 00 00 00 00 00 00 08 38 56 44 44 54 31 36 ,........8VDDT16 +0050: 36 34 41 47 2d 32 36 35 41 31 20 01 00 01 2c 63 64AG-265A1 ...,c +0060: 22 25 ab 00 00 00 00 00 00 00 00 00 00 00 00 00 "%.............. +0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ + + +PCI DOUBLE-ENUMERATION WOES +=========================== + +If you're not using PCI-X cards and are simply using 32-bit and/or +33 MHz cards via extenders and the like, you may notice that the +initial pci scan reports various devices twice ... and configuration +does not succeed (one or more devices are enumerated twice). To correct +this we replaced the 2K ohm resistor on the IDSEL line(s) with a +22 ohm resistor and the problem went away. This change hasn't broken +anything yet -- use at your own risk. + +We never tested anything other than 33 MHz/32-bit cards. If you have +the chance to do this, please let me know how things turn out :-) + + + +Regards, +--Scott +<smcnutt@artesyncp.com> + diff --git a/doc/README.ppc440 b/doc/README.ppc440 new file mode 100644 index 0000000..acb0c6f --- /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 +<smcnutt@artesyncp.com> + |