diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/README.mx28evk | 2 | ||||
| -rw-r--r-- | doc/README.spear | 54 | ||||
| -rw-r--r-- | doc/README.switch_config | 25 | ||||
| -rw-r--r-- | doc/kwboot.1 | 84 |
4 files changed, 150 insertions, 15 deletions
diff --git a/doc/README.mx28evk b/doc/README.mx28evk index c6c3d37830..571dfdab8d 100644 --- a/doc/README.mx28evk +++ b/doc/README.mx28evk @@ -17,7 +17,7 @@ Jumper configuration To boot MX28EVK from an SD card, set the boot mode DIP switches as: * Boot Mode Select: 1 0 0 1 (Boot from SD card Slot 0 - U42) - * JTAG PSWITCH RESET: To the left (reset enabled) + * JTAG PSWITCH RESET: To the right (reset disabled) * Battery Source: Down * Wall 5V: Up * VDD 5V: To the left (off) diff --git a/doc/README.spear b/doc/README.spear index a8b1052449..0789b3fd27 100644 --- a/doc/README.spear +++ b/doc/README.spear @@ -6,9 +6,10 @@ SPEAr600 is also known as SPEArPlus and SPEAr300 is also known as SPEArBasic The SPEAr SoC family embeds a customizable logic that can be programmed one-time by a customer at silicon mask level (i.e. not at runtime!). -We are now adding the support in u-boot for two SoC: SPEAr600 and SPEAr3xx. +U-Boot supports four SoCs: SPEAr600, SPEAr3xx -All 4 SoCs share common peripherals. +All 4 SoCs (SPEAr3xx and SPEAr600) share common peripherals. SPEAr300 and +SPEAr600 do not have EMI. 1. ARM926ejs core based (sp600 has two cores, the 2nd handled only in Linux) 2. FastEthernet (sp600 has Gbit version, but same controller - GMAC) @@ -22,7 +23,7 @@ All 4 SoCs share common peripherals. 10. others .. Everything is supported in Linux. -u-boot is not currently supporting all peripeharls (just a few as listed below). +u-boot is currently not supporting all peripeharls (just a few as listed below). 1. USB Device 2. NAND controller (FSMC) 3. Serial Memory Interface @@ -31,18 +32,43 @@ u-boot is not currently supporting all peripeharls (just a few as listed below). 5. UART Build options - make spear600_config + make spear320_config + spear320 build with environment variables placed at default + location i.e. Serial NOR device + make spear320_pnor_config + This option generates a uboot image that supports emi controller + for CFI compliant parallel NOR flash. Environment variables are + placed in Parallel NOR device + make spear320_nand_config + spear320 build with environment variables placed in NAND device + make spear320_usbtty_config + spear320 build with usbtty terminal as default and environment + placed at default location + make spear320_usbtty_pnor_config + spear320 build with usbtty terminal as default and environment + placed in pnor device + make spear320_usbtty_nand_config + Build with usbtty terminal as default and environment placed in + NAND device make spear300_config + make spear300_nand_config + make spear300_usbtty_config + make spear300_usbtty_nand_config make spear310_config - make spear320_config - -Further options - make ENV=NAND (supported by all 4 SoCs) - - This option generates a uboot image that saves environment inn NAND + make spear310_pnor_config + make spear310_nand_config + make spear310_usbtty_config + make spear310_usbtty_pnor_config + make spear310_usbtty_nand_config + make spear600_config + make spear600_nand_config + make spear600_usbtty_config + make spear600_usbtty_nand_config - make CONSOLE=USB (supported by all 4 SoCs) - - This option generates a uboot image for using usbdevice as a tty i/f +Mac id storage and retrieval in spear platforms - make FLASH=PNOR (supported by SPEAr310 and SPEAr320) - - This option generates a uboot image that supports emi controller for - CFI compliant parallel NOR flash +Please read doc/README.enetaddr for the implementation guidelines for mac id +usage. Basically, environment has precedence over board specific storage. The +ethaddr beeing used for the network interface is always taken only from +environment variables. Although, we can check the mac id programmed in i2c +memory by using chip_config command diff --git a/doc/README.switch_config b/doc/README.switch_config new file mode 100644 index 0000000000..f8903738e1 --- /dev/null +++ b/doc/README.switch_config @@ -0,0 +1,25 @@ +On the enbw_cmc board is a KSZ8864RMN switch which needs +configured through spi before working. This is done on +startup from u-boot through a config file stored at an +address specified in the "hwconfig" environment variable, +subcommand "config". + +For example on the enbw_cmc board: + +hwconfig=switch:lan=on,pwl=off,config=0x60160000 + +The file has the following structure: + +- a comment starts with a '#' or a ';' and ends with a newline +- The switch needs for its config a reg/value pair, so we + have two columns in the file: + reg : contains the register address + value: contains a 8 bit register value + This 2 columns are seperated through space or tab. + +example (minimal configuration on the enbw_cmc board): + +;reg value comment +;----------------------------------------- +0x01 0x00 +0x01 0x01 ; Start Switch with this configuration diff --git a/doc/kwboot.1 b/doc/kwboot.1 new file mode 100644 index 0000000000..ed0839836e --- /dev/null +++ b/doc/kwboot.1 @@ -0,0 +1,84 @@ +.TH KWBOOT 1 "2012-05-19" + +.SH NAME +kwboot \- Boot Marvell Kirkwood SoCs over a serial link. +.SH SYNOPSIS +.B kwboot +.RB [ "-b \fIimage\fP" ] +.RB [ "-p" ] +.RB [ "-t" ] +.RB [ "-B \fIbaudrate\fP" ] +.RB \fITTY\fP +.SH "DESCRIPTION" + +The \fBmkimage\fP program boots boards based on Marvell's Kirkwood +platform over their integrated UART. Boot image files will typically +contain a second stage boot loader, such as U-Boot. The image file +must conform to Marvell's BootROM firmware image format +(\fIkwbimage\fP), created using a tool such as \fBmkimage\fP. + +Following power-up or a system reset, system BootROM code polls the +UART for a brief period of time, sensing a handshake message which +initiates an image upload. This program sends this boot message until +it receives a positive acknowledgement. The image is transfered using +Xmodem. + +Additionally, this program implements a minimal terminal mode, which +can be used either standalone, or entered immediately following boot +image transfer completion. This is often useful to catch early boot +messages, or to manually interrupt a default boot procedure performed +by the second-stage loader. + +.SH "OPTIONS" + +.TP +.BI "\-b \fIimage\fP" +Handshake; then upload file \fIimage\fP over \fITTY\fP. + +Note that for the encapsulated boot code to be executed, \fIimage\fP +must be of type "UART boot" (0x69). Boot images of different types, +such as backup images of vendor firmware downloaded from flash memory +(type 0x8B), will not work (or not as expected). See \fB-p\fP for a +workaround. + +This mode writes handshake status and upload progress indication to +stdout. + +.TP +.BI "\-p" +In combination with \fB-b\fP, patches the header in \fIimage\fP prior +to upload, to "UART boot" type. + +This option attempts on-the-fly conversion of some none-UART image +types, such as images which were originally formatted to be stored in +flash memory. + +Conversion is performed in memory. The contents of \fIimage\fP will +not be altered. + +.TP +.BI "\-t" +Run a terminal program, connecting standard input and output to +.RB \fITTY\fP. + +If used in combination with \fB-b\fP, terminal mode is entered +immediately following a successful image upload. + +If standard I/O streams connect to a console, this mode will terminate +after receiving 'ctrl-\\' followed by 'c' from console input. + +.TP +.BI "\-B \fIbaudrate\fP" +Adjust the baud rate on \fITTY\fP. Default rate is 115200. + +.SH "SEE ALSO" +.PP +\fBmkimage\fP(1) + +.SH "AUTHORS" + +Daniel Stodden <daniel.stodden@gmail.com> +.br +Luka Perkov <uboot@lukaperkov.net> +.br +David Purdy <david.c.purdy@gmail.com> |