summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/README.fdt-control6
-rw-r--r--doc/README.p1010rdb199
-rw-r--r--doc/README.ramboot-ppc85xx102
-rw-r--r--doc/README.watchdog3
-rw-r--r--doc/feature-removal-schedule.txt19
-rw-r--r--doc/git-mailrc3
6 files changed, 318 insertions, 14 deletions
diff --git a/doc/README.fdt-control b/doc/README.fdt-control
index 8352835..5963f78 100644
--- a/doc/README.fdt-control
+++ b/doc/README.fdt-control
@@ -142,7 +142,11 @@ join the two:
and then flash image.bin onto your board.
-You cannot use both of these options at the same time.
+If CONFIG_OF_HOSTFILE is defined, then it will be read from a file on
+startup. This is only useful for sandbox. Use the -d flag to U-Boot to
+specify the file to read.
+
+You cannot use more than one of these options at the same time.
If you wish to put the fdt at a different address in memory, you can
define the "fdtcontroladdr" environment variable. This is the hex
diff --git a/doc/README.p1010rdb b/doc/README.p1010rdb
new file mode 100644
index 0000000..dee63d7
--- /dev/null
+++ b/doc/README.p1010rdb
@@ -0,0 +1,199 @@
+Overview
+=========
+The P1010RDB is a Freescale reference design board that hosts the P1010 SoC.
+
+The P1010 is a cost-effective, low-power, highly integrated host processor
+based on a Power Architecture e500v2 core (maximum core frequency 800/1000 MHz),
+that addresses the requirements of several routing, gateways, storage, consumer,
+and industrial applications. Applications of interest include the main CPUs and
+I/O processors in network attached storage (NAS), the voice over IP (VoIP)
+router/gateway, and wireless LAN (WLAN) and industrial controllers.
+
+The P1010RDB board features are as follows:
+Memory subsystem:
+ - 1Gbyte unbuffered DDR3 SDRAM discrete devices (32-bit bus)
+ - 32 Mbyte NOR flash single-chip memory
+ - 32 Mbyte NAND flash memory
+ - 256 Kbit M24256 I2C EEPROM
+ - 16 Mbyte SPI memory
+ - I2C Board EEPROM 128x8 bit memory
+ - SD/MMC connector to interface with the SD memory card
+Interfaces:
+ - PCIe:
+ - Lane0: x1 mini-PCIe slot
+ - Lane1: x1 PCIe standard slot
+ - SATA:
+ - 1 internal SATA connector to 2.5" 160G SATA2 HDD
+ - 1 eSATA connector to rear panel
+ - 10/100/1000 BaseT Ethernet ports:
+ - eTSEC1, RGMII: one 10/100/1000 port using Vitesse VSC8641XKO
+ - eTSEC2, SGMII: one 10/100/1000 port using Vitesse VSC8221
+ - eTSEC3, SGMII: one 10/100/1000 port using Vitesse VSC8221
+ - USB 2.0 port:
+ - x1 USB2.0 port: via an ULPI PHY to micro-AB connector
+ - x1 USB2.0 poort via an internal PHY to micro-AB connector
+ - FlexCAN ports:
+ - x2 DB-9 female connectors for FlexCAN bus(revision 2.0B)
+ interface;
+ - DUART interface:
+ - DUART interface: supports two UARTs up to 115200 bps for
+ console display
+ - J45 connectors are used for these 2 UART ports.
+ - TDM
+ - 2 FXS ports connected via an external SLIC to the TDM
+ interface. SLIC is controllled via SPI.
+ - 1 FXO port connected via a relay to FXS for switchover to
+ POTS
+Board connectors:
+ - Mini-ITX power supply connector
+ - JTAG/COP for debugging
+IEEE Std. 1588 signals for test and measurement
+Real-time clock on I2C bus
+POR
+ - support critical POR setting changed via switch on board
+PCB
+ - 6-layer routing (4-layer signals, 2-layer power and ground)
+
+
+Serial Port Configuration on P1010RDB
+=====================================
+Configure the serial port of the attached computer with the following values:
+ -Data rate: 115200 bps
+ -Number of data bits: 8
+ -Parity: None
+ -Number of Stop bits: 1
+ -Flow Control: Hardware/None
+
+
+Settings of DIP-switch
+======================
+ SW4[1:4]= 1111 and SW6[4]=0 for boot from 16bit NOR flash
+ SW4[1:4]= 1000 and SW6[4]=1 for boot from 8bit NAND flash
+ SW4[1:4]= 0110 and SW6[4]=0 for boot from SPI flash
+Note: 1 stands for 'on', 0 stands for 'off'
+
+
+Setting of hwconfig
+===================
+If FlexCAN or TDM is needed, please set "fsl_p1010mux:tdm_can=can" or
+"fsl_p1010mux:tdm_can=tdm" explicitly in u-booot prompt as below for example:
+setenv hwconfig "fsl_p1010mux:tdm_can=tdm;usb1:dr_mode=host,phy_type=utmi"
+By default, don't set fsl_p1010mux:tdm_can, in this case, spi chip selection
+is set to spi-flash instead of to SLIC/TDM/DAC and tdm_can_sel is set to TDM
+instead of to CAN/UART1.
+
+
+Build and burn u-boot to NOR flash
+==================================
+1. Build u-boot.bin image
+ export ARCH=powerpc
+ export CROSS_COMPILE=/your_path/powerpc-linux-gnu-
+ make P1010RDB_NOR
+
+2. Burn u-boot.bin into NOR flash
+ => tftp $loadaddr $uboot
+ => protect off eff80000 +$filesize
+ => erase eff80000 +$filesize
+ => cp.b $loadaddr eff80000 $filesize
+
+3. Check SW4[1:4]= 1111 and SW6[4]=0, then power on.
+
+
+Alternate NOR bank
+============================
+1. Burn u-boot.bin into alternate NOR bank
+ => tftp $loadaddr $uboot
+ => protect off eef80000 +$filesize
+ => erase eef80000 +$filesize
+ => cp.b $loadaddr eef80000 $filesize
+
+2. Switch to alternate NOR bank
+ => mw.b ffb00009 1
+ => reset
+ or set SW1[8]= ON
+
+SW1[8]= OFF: Upper bank used for booting start
+SW1[8]= ON: Lower bank used for booting start
+CPLD NOR bank selection register address 0xFFB00009 Bit[0]:
+0 - boot from upper 4 sectors
+1 - boot from lower 4 sectors
+
+
+Build and burn u-boot to NAND flash
+===================================
+1. Build u-boot.bin image
+ export ARCH=powerpc
+ export CROSS_COMPILE=/your_path/powerpc-linux-gnu-
+ make P1010RDB_NAND
+
+2. Burn u-boot-nand.bin into NAND flash
+ => tftp $loadaddr $uboot-nand
+ => nand erase 0 $filesize
+ => nand write $loadaddr 0 $filesize
+
+3. Check SW4[1:4]= 1000 and SW6[4]=1, then power on.
+
+
+
+Build and burn u-boot to SPI flash
+==================================
+1. Build u-boot-spi.bin image
+ make P1010RDB_SPIFLASH_config; make
+ Boot up kernel with rootfs.ext2.gz.uboot.p1010rdb
+ Download u-boot.bin to linux and you can find some config files
+ under /usr/share such as config_xx.dat. Do below command:
+ boot_format config_ddr3_1gb_p1010rdb_800M.dat u-boot.bin -spi \
+ u-boot-spi.bin
+ to generate u-boot-spi.bin.
+
+2. Burn u-boot-spi.bin into SPI flash
+ => tftp $loadaddr $uboot-spi
+ => sf erase 0 100000
+ => sf write $loadaddr 0 $filesize
+
+3. Check SW4[1:4]= 0110 and SW6[4]=0, then power on.
+
+
+
+CPLD POR setting registers
+==========================
+1. Set POR switch selection register (addr 0xFFB00011) to 0.
+2. Write CPLD POR registers (BCSR0~BCSR3, addr 0xFFB00014~0xFFB00017) with
+ proper values.
+ If change boot ROM location to NOR or NAND flash, need write the IFC_CS0
+ switch command by I2C.
+3. Send reset command.
+ After reset, the new POR setting will be implemented.
+
+Two examples are given in below:
+Switch from NOR to NAND boot with default frequency:
+ => i2c dev 0
+ => i2c mw 18 1 f9
+ => i2c mw 18 3 f0
+ => mw.b ffb00011 0
+ => mw.b ffb00017 1
+ => reset
+Switch from NAND to NOR boot with Core/CCB/DDR (800/400/667 MHz):
+ => i2c dev 0
+ => i2c mw 18 1 f1
+ => i2c mw 18 3 f0
+ => mw.b ffb00011 0
+ => mw.b ffb00014 2
+ => mw.b ffb00015 5
+ => mw.b ffb00016 3
+ => mw.b ffb00017 f
+ => reset
+
+
+
+Boot Linux from network using TFTP on P1010RDB
+==============================================
+Place uImage, p1010rdb.dtb and rootfs files in the TFTP disk area.
+ => tftp 1000000 uImage
+ => tftp 2000000 p1010rdb.dtb
+ => tftp 3000000 rootfs.ext2.gz.uboot.p1010rdb
+ => bootm 1000000 3000000 2000000
+
+
+Please contact your local field applications engineer or sales representative
+to obtain related documents, such as P1010-RDB User Guide for details.
diff --git a/doc/README.ramboot-ppc85xx b/doc/README.ramboot-ppc85xx
new file mode 100644
index 0000000..8ed45fb
--- /dev/null
+++ b/doc/README.ramboot-ppc85xx
@@ -0,0 +1,102 @@
+ RAMBOOT for MPC85xx Platforms
+ ==============================
+
+RAMBOOT literally means boot from DDR. But since DDR is volatile memory some
+pre-mechanism is required to load the DDR with the bootloader binary.
+- In case of SD and SPI boot this is done by BootROM code inside the chip
+ itself.
+- In case of NAND boot FCM supports loading initial 4K code from NAND flash
+ which can initialize the DDR and get the complete bootloader copied to DDR.
+
+In addition to the above there could be some more methods to initialize the DDR
+and load it manually.
+Two of them are described below.There is also an explanation as to where these
+methods could be handy.
+1. Load the RAM based bootloader onto DDR via JTAG/BDI interface. And then
+ execute the bootloader from DDR.
+ This may be handy in the following cases:
+ - In very early stage of platform bringup where other boot options are not
+ functional because of various reasons.
+ - In case the support to program the flashes on the board is not available.
+
+2. Load the RAM based bootloader onto DDR using already existing bootloader on
+ the board.And then execute the bootloader from DDR.
+ Some usecases where this may be used:
+ - While developing some new feature of u-boot, for example USB driver or
+ SPI driver.
+ Suppose the board already has a working bootloader on it. And you would
+ prefer to keep it intact, at the same time want to test your bootloader.
+ In this case you can get your test bootloader binary into DDR via tftp
+ for example. Then execute the test bootloader.
+ - Suppose a platform already has a propreitery bootloader which does not
+ support for example AMP boot. In this case also RAM boot loader can be
+ utilized.
+
+ So basically when the original bootloader is required to be kept intact
+ RAM based bootloader can offer an updated bootloader on the system.
+
+Both the above Bootloaders are slight variants of SDcard or SPI Flash
+bootloader or for that matter even NAND bootloader.
+All of them define CONFIG_SYS_RAMBOOT.
+The main difference among all of them is the way the pre-environment is getting
+configured and who is doing that.
+- In case of SD card and SPI flash bootloader this is done by On Chip BootROM inside the Si itself.
+- In case of NAND boot SPL/TPL code does it with some support from Si itself.
+- In case of the pure RAM based bootloaders we have to do it by JTAG manually or already existing bootloader.
+
+How to use them:
+1. Using JTAG
+ Boot up in core hold off mode or stop the core after reset using JTAG
+ interface.
+ Preconfigure DDR/L2SRAM through JTAG interface.
+ - setup DDR controller registers.
+ - setup DDR LAWs
+ - setup DDR TLB
+ Load the RAM based boot loader to the proper location in DDR/L2SRAM.
+ set up IAR (Instruction counter properly)
+ Enable the core to execute.
+
+2. Using already existing bootloader.
+ get the rambased boot loader binary into DDR/L2SRAM via tftp.
+ execute the RAM based bootloader.
+ => tftp 11000000 u-boot-ram.bin
+ => go 1107f000
+
+Please note that L2SRAM can also be used instead of DDR if the SOC has
+sufficient size of L2SRAM.
+
+Necessary Code changes Required:
+=====================================
+Please note that below mentioned changes are for 85xx platforms.
+They have been tested on P1020/P2020/P1010 RDB.
+
+The main difference between the above two methods from technical perspective is
+that in 1st case SOC is just out of reset so it is in default configuration.
+(CCSRBAR is at 0xff700000).
+In the 2nd case bootloader has already re-located CCSRBAR to 0xffe00000
+
+1. File name-> boards.cfg
+ There can be added specific Make options for RAMBoot. We can keep different
+ options for the two cases mentioned above.
+ for example
+ P1020RDB_JTAG_RAMBOOT and P1020RDB_GO_RAMBOOT.
+
+2. platform config file
+ for example include/configs/P1_P2_RDB.h
+
+ #ifdef CONFIG_RAMBOOT
+ #define CONFIG_SDCARD
+ #endif
+
+ This will finally use the CONFIG_SYS_RAMBOOT.
+
+3. File name-> arch/powerpc/include/asm/config_mpc85xx.h
+ In the section of the particular SOC, for example P1020,
+
+ #if defined(CONFIG_GO)
+ #define CONFIG_SYS_CCSRBAR_DEFAULT 0xffe00000
+ #else
+ #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff700000
+ #endif
+
+For JTAG RAMBOOT this is not required because CCSRBAR is at ff700000.
diff --git a/doc/README.watchdog b/doc/README.watchdog
index ee65008..33f31c2 100644
--- a/doc/README.watchdog
+++ b/doc/README.watchdog
@@ -27,3 +27,6 @@ CONFIG_IMX_WATCHDOG
Available for i.mx31/35/5x/6x to service the watchdog. This is not
automatically set because some boards (vision2) still need to define
their own hw_watchdog_reset routine.
+
+CONFIG_XILINX_TB_WATCHDOG
+ Available for Xilinx Axi platforms to service timebase watchdog timer.
diff --git a/doc/feature-removal-schedule.txt b/doc/feature-removal-schedule.txt
index ce72861..1c79c14 100644
--- a/doc/feature-removal-schedule.txt
+++ b/doc/feature-removal-schedule.txt
@@ -7,20 +7,15 @@ file.
---------------------------
-What: Remove CONFIG_CMD_MEMTEST from default list
-When: Release v2013.07
+What: Remove unused CONFIG_SYS_MEMTEST_START/END
+When: Release v2013.10
-Why: The "mtest" command is of little practical use (if any), and
- experience has shown that a large number of board configu-
- rations define useless or even dangerous start and end
- addresses. If not even the board maintainers are able to
- figure out which memory range can be reliably tested, how can
- we expect such from the end users? As this problem comes up
- repeatedly, we rather do not enable this command by default,
- so only people who know what they are doing will be confronted
- with it.
+Why: As the 'mtest' command is no longer default, a number of platforms
+ have not opted to turn the command back on and thus provide unused
+ defines (which are likely to be propogated to new platforms from
+ copy/paste). Remove these defines when unused.
-Who: Wolfgang Denk <wd@denx.de>
+Who: Tom Rini <trini@ti.com>
---------------------------
diff --git a/doc/git-mailrc b/doc/git-mailrc
index 0f23776..e3a47c4 100644
--- a/doc/git-mailrc
+++ b/doc/git-mailrc
@@ -34,6 +34,7 @@ alias sjg Simon Glass <sjg@chromium.org>
alias smcnutt Scott McNutt <smcnutt@psyent.com>
alias sonic Sonic Zhang <sonic.adi@gmail.com>
alias stroese Stefan Roese <sr@denx.de>
+alias trini Tom Rini <trini@ti.com>
alias vapier Mike Frysinger <vapier@gentoo.org>
alias wd Wolfgang Denk <wd@denx.de>
@@ -54,7 +55,7 @@ alias s5pc samsung
alias samsung uboot, prom
alias tegra uboot, sjg, Tom Warren <twarren@nvidia.com>, Stephen Warren <swarren@nvidia.com>
alias tegra2 tegra
-alias ti uboot, Tom Rini <trini@ti.com>
+alias ti uboot, trini
alias avr32 uboot, abiessmann