ASR_BASE
Change-Id: Icf3719cc0afe3eeb3edc7fa80a2eb5199ca9dda1
diff --git a/marvell/uboot/doc/SPI/README.dual-flash b/marvell/uboot/doc/SPI/README.dual-flash
new file mode 100644
index 0000000..6c88d65
--- /dev/null
+++ b/marvell/uboot/doc/SPI/README.dual-flash
@@ -0,0 +1,92 @@
+SPI/QSPI Dual flash connection modes:
+=====================================
+
+This describes how SPI/QSPI flash memories are connected to a given
+controller in a single chip select line.
+
+Current spi_flash framework supports, single flash memory connected
+to a given controller with single chip select line, but there are some
+hw logics(ex: xilinx zynq qspi) that describes two/dual memories are
+connected with a single chip select line from a controller.
+
+"dual_flash" from include/spi.h describes these types of connection mode
+
+Possible connections:
+--------------------
+SF_SINGLE_FLASH:
+ - single spi flash memory connected with single chip select line.
+
+ +------------+ CS +---------------+
+ | |----------------------->| |
+ | Controller | I0[3:0] | Flash memory |
+ | SPI/QSPI |<======================>| (SPI/QSPI) |
+ | | CLK | |
+ | |----------------------->| |
+ +------------+ +---------------+
+
+SF_DUAL_STACKED_FLASH:
+ - dual spi/qspi flash memories are connected with a single chipselect
+ line and these two memories are operating stacked fasion with shared buses.
+ - xilinx zynq qspi controller has implemented this feature [1]
+
+ +------------+ CS +---------------+
+ | |---------------------->| |
+ | | I0[3:0] | Upper Flash |
+ | | +=========>| memory |
+ | | | CLK | (SPI/QSPI) |
+ | | | +---->| |
+ | Controller | CS | | +---------------+
+ | SPI/QSPI |------------|----|---->| |
+ | | I0[3:0] | | | Lower Flash |
+ | |<===========+====|====>| memory |
+ | | CLK | | (SPI/QSPI) |
+ | |-----------------+---->| |
+ +------------+ +---------------+
+
+ - two memory flash devices should has same hw part attributes (like size,
+ vendor..etc)
+ - Configurations:
+ on LQSPI_CFG register, Enable TWO_MEM[BIT:30] on LQSPI_CFG
+ Enable U_PAGE[BIT:28] if U_PAGE flag set - upper memory
+ Disable U_PAGE[BIT:28] if U_PAGE flag unset - lower memory
+ - Operation:
+ accessing memories serially like one after another.
+ by default, if U_PAGE is unset lower memory should accessible,
+ once user wants to access upper memory need to set U_PAGE.
+
+SPI_FLASH_CONN_DUALPARALLEL:
+ - dual spi/qspi flash memories are connected with a single chipselect
+ line and these two memories are operating parallel with separate buses.
+ - xilinx zynq qspi controller has implemented this feature [1]
+
+ +-------------+ CS +---------------+
+ | |---------------------->| |
+ | | I0[3:0] | Upper Flash |
+ | |<=====================>| memory |
+ | | CLK | (SPI/QSPI) |
+ | |---------------------->| |
+ | Controller | CS +---------------+
+ | SPI/QSPI |---------------------->| |
+ | | I0[3:0] | Lower Flash |
+ | |<=====================>| memory |
+ | | CLK | (SPI/QSPI) |
+ | |---------------------->| |
+ +-------------+ +---------------+
+
+ - two memory flash devices should has same hw part attributes (like size,
+ vendor..etc)
+ - Configurations:
+ Need to enable SEP_BUS[BIT:29],TWO_MEM[BIT:30] on LQSPI_CFG register.
+ - Operation:
+ Even bits, i.e. bit 0, 2, 4 ., of a data word is located in the lower memory
+ and odd bits, i.e. bit 1, 3, 5, ., of a data word is located in the upper memory.
+
+Note: Technically there is only one CS line from the controller, but
+zynq qspi controller has an internal hw logic to enable additional CS
+when controller is configured for dual memories.
+
+[1] http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf
+
+--
+Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
+05-01-2014.
diff --git a/marvell/uboot/doc/SPI/README.ftssp010_spi_test b/marvell/uboot/doc/SPI/README.ftssp010_spi_test
new file mode 100644
index 0000000..1d86f36
--- /dev/null
+++ b/marvell/uboot/doc/SPI/README.ftssp010_spi_test
@@ -0,0 +1,41 @@
+SPI Flash test on Faraday A369 EVB:
+==================================
+
+U-Boot 2014.01-rc2-g3444b6f (Dec 20 2013 - 10:58:40)
+
+CPU: FA626TE 528 MHz
+AHB: 132 MHz
+APB: 66 MHz
+I2C: ready
+DRAM: 256 MiB
+MMU: on
+NAND: 512 MiB
+MMC: ftsdc010: 0
+*** Warning - bad CRC, using default environment
+
+In: serial
+Out: serial
+Err: serial
+Net: FTGMAC100#0
+Hit any key to stop autoboot: 0
+=> sf probe 0:0
+SF: Detected MX25L1605D with page size 256 Bytes, erase size 64 KiB, total 2 MiB
+=> sf read 0x10800000 0 0x400
+SF: 1024 bytes @ 0x0 Read: OK
+=> md 0x10800000
+10800000: ea000013 e59ff014 e59ff014 e59ff014 ................
+10800010: e59ff014 e59ff014 e59ff014 e59ff014 ................
+10800020: 1ff7b0c0 1ff7b120 1ff7b180 1ff7b1e0 .... ...........
+10800030: 1ff7b240 1ff7b2a0 1ff7b300 deadbeef @...............
+10800040: 10800000 0002c1f0 0007409c 00032048 .........@..H ..
+10800050: 1fd6af40 e10f0000 e3c0001f e38000d3 @...............
+10800060: e129f000 eb000001 eb000223 e12fff1e ..).....#...../.
+10800070: e3a00000 ee070f1e ee080f17 ee070f15 ................
+10800080: ee070f9a ee110f10 e3c00c03 e3c00087 ................
+10800090: e3c00a02 e3800002 e3800a01 ee010f10 ................
+108000a0: e1a0c00e eb007a68 e1a0e00c e1a0f00e ....hz..........
+108000b0: e1a00000 e1a00000 e1a00000 e1a00000 ................
+108000c0: e51fd078 e58de000 e14fe000 e58de004 x.........O.....
+108000d0: e3a0d013 e169f00d e1a0e00f e1b0f00e ......i.........
+108000e0: e24dd048 e88d1fff e51f20a0 e892000c H.M...... ......
+108000f0: e28d0048 e28d5034 e1a0100e e885000f H...4P..........
diff --git a/marvell/uboot/doc/SPI/README.sandbox-spi b/marvell/uboot/doc/SPI/README.sandbox-spi
new file mode 100644
index 0000000..bb73eaf
--- /dev/null
+++ b/marvell/uboot/doc/SPI/README.sandbox-spi
@@ -0,0 +1,64 @@
+Sandbox SPI/SPI Flash Implementation
+====================================
+
+U-Boot supports SPI and SPI flash emuation in sandbox. This must be enabled
+using the --spi_sf paramter when starting U-Boot.
+
+For example:
+
+$ make O=sandbox sandbox_config
+$ make O=sandbox
+$ ./sandbox/u-boot --spi_sf 0:0:W25Q128:b/chromeos_peach/out/image.bin
+
+The four parameters to spi_sf are:
+
+ SPI bus number (typically 0)
+ SPI chip select number (typically 0)
+ SPI chip to emulate
+ File containing emulated data
+
+Supported chips are W25Q16 (2MB), W25Q32 (4MB) and W25Q128 (16MB). Once
+U-Boot it started you can use 'sf' commands as normal. For example:
+
+$ ./b/sandbox/u-boot --spi_sf 0:0:W25Q128:b/chromeos_peach/out/image.bin \
+ -c "sf probe; sf test 0 100000; sf read 0 1000 1000; \
+ sf erase 1000 1000; sf write 0 1000 1000"
+
+
+U-Boot 2013.10-00237-gd4e0fdb (Nov 07 2013 - 20:08:15)
+
+DRAM: 128 MiB
+Using default environment
+
+In: serial
+Out: serial
+Err: serial
+SF: Detected W25Q128BV with page size 256 Bytes, erase size 4 KiB, total 16 MiB
+SPI flash test:
+0 erase: 1 ticks, 1024000 KiB/s 8192.000 Mbps
+1 check: 2 ticks, 512000 KiB/s 4096.000 Mbps
+2 write: 6 ticks, 170666 KiB/s 1365.328 Mbps
+3 read: 0 ticks, 1048576000 KiB/s -201326.-592 Mbps
+Test passed
+0 erase: 1 ticks, 1024000 KiB/s 8192.000 Mbps
+1 check: 2 ticks, 512000 KiB/s 4096.000 Mbps
+2 write: 6 ticks, 170666 KiB/s 1365.328 Mbps
+3 read: 0 ticks, 1048576000 KiB/s -201326.-592 Mbps
+SF: 4096 bytes @ 0x1000 Read: OK
+SF: 4096 bytes @ 0x1000 Erased: OK
+SF: 4096 bytes @ 0x1000 Written: OK
+
+
+Since the SPI bus is fully implemented as well as the SPI flash connected to
+it, you can also use low-level SPI commands to access the flash. For example
+this reads the device ID from the emulated chip:
+
+=> sspi 0 32 9f
+FFEF4018
+
+
+Simon Glass
+sjg@chromium.org
+7/11/2013
+Note that the sandbox SPI implementation was written by Mike Frysinger
+<vapier@gentoo.org>.
diff --git a/marvell/uboot/doc/SPI/README.sh_qspi_test b/marvell/uboot/doc/SPI/README.sh_qspi_test
new file mode 100644
index 0000000..8a33fec
--- /dev/null
+++ b/marvell/uboot/doc/SPI/README.sh_qspi_test
@@ -0,0 +1,38 @@
+-------------------------------------------------
+ Simple steps used to test the SH-QSPI at U-Boot
+-------------------------------------------------
+
+#0, Currently, SH-QSPI is used by lager board (Renesas ARM SoC R8A7790)
+ and koelsch board (Renesas ARM SoC R8A7791). These boot from SPI ROM
+ basically. Thus, U-Boot start, SH-QSPI will is operating normally.
+
+#1, build U-Boot and load u-boot.bin
+
+ => tftpboot 40000000 u-boot.bin
+ sh_eth Waiting for PHY auto negotiation to complete.. done
+ sh_eth: 100Base/Half
+ Using sh_eth device
+ TFTP from server 192.168.169.1; our IP address is 192.168.169.79
+ Filename 'u-boot.bin'.
+ Load address: 0x40000000
+ Loading: ############
+ 2.5 MiB/s
+ done
+ Bytes transferred = 175364 (2ad04 hex)
+
+#2, Commands to erase/write u-boot to flash device
+
+ Note: This method is description of the lager board. If you want to use the
+ other boards, please change the value according to each environment.
+
+ => sf probe 0
+ SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 64 KiB, total 64 MiB
+ => sf erase 80000 40000
+ SF: 262144 bytes @ 0x80000 Erased: OK
+ => sf write 40000000 80000 175364
+ SF: 1528676 bytes @ 0x80000 Written: OK
+ =>
+
+#3, Push reset button.
+
+ If you're written correctly and driver works properly, U-Boot starts.
diff --git a/marvell/uboot/doc/SPI/README.ti_qspi_dra_test b/marvell/uboot/doc/SPI/README.ti_qspi_dra_test
new file mode 100644
index 0000000..fe37857
--- /dev/null
+++ b/marvell/uboot/doc/SPI/README.ti_qspi_dra_test
@@ -0,0 +1,48 @@
+-------------------------------------------------
+ Simple steps used to test the QSPI at U-Boot
+-------------------------------------------------
+
+For #1, build the patched U-Boot and load MLO/u-boot.img
+
+----------------------------------
+Boot from another medium like MMC
+----------------------------------
+
+U-Boot# mmc dev 0
+mmc0 is current device
+U-Boot# fatload mmc 0 0x82000000 MLO
+reading MLO
+55872 bytes read in 8 ms (6.7 MiB/s)
+U-Boot# fatload mmc 0 0x83000000 u-boot.img
+reading u-boot.img
+248600 bytes read in 19 ms (12.5 MiB/s)
+
+--------------------------------------------------
+Commands to erase/write u-boot/mlo to flash device
+--------------------------------------------------
+U-Boot# sf probe 0
+SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB, mapped at 5c000000
+SF: Warning - Only lower 16MiB accessible, Full access #define CONFIG_SPI_FLASH_BAR
+U-Boot# sf erase 0 0x10000
+SF: 65536 bytes @ 0x0 Erased: OK
+U-Boot# sf erase 0x20000 0x10000
+SF: 65536 bytes @ 0x20000 Erased: OK
+U-Boot# sf erase 0x30000 0x10000
+SF: 65536 bytes @ 0x30000 Erased: OK
+U-Boot# sf erase 0x40000 0x10000
+SF: 65536 bytes @ 0x40000 Erased: OK
+U-Boot# sf erase 0x50000 0x10000
+SF: 65536 bytes @ 0x50000 Erased: OK
+U-Boot# sf erase 0x60000 0x10000
+SF: 65536 bytes @ 0x60000 Erased: OK
+U-Boot# sf write 82000000 0 0x10000
+SF: 65536 bytes @ 0x0 Written: OK
+U-Boot# sf write 83000000 0x20000 0x60000
+SF: 393216 bytes @ 0x20000 Written: OK
+
+For #2, set sysboot to QSPI-1 boot mode(SYSBOOT[5:0] = 100110) and power
+on. ROM should find the GP header at offset 0 and load/execute SPL. SPL
+then detects that ROM was in QSPI-1 mode (boot code 10) and attempts to
+find a U-Boot image header at offset 0x20000 (set in the config file)
+and proceeds to load that image using the U-Boot image payload offset/size
+from the header. It will then start U-Boot.
diff --git a/marvell/uboot/doc/SPI/README.ti_qspi_flash b/marvell/uboot/doc/SPI/README.ti_qspi_flash
new file mode 100644
index 0000000..1b86d01
--- /dev/null
+++ b/marvell/uboot/doc/SPI/README.ti_qspi_flash
@@ -0,0 +1,47 @@
+QSPI U-boot support
+------------------
+
+Host processor is connected to serial flash device via qpsi
+interface. QSPI is a kind of spi module that allows single,
+dual and quad read access to external spi devices. The module
+has a memory mapped interface which provide direct interface
+for accessing data form external spi devices.
+
+The one QSPI in the device is primarily intended for fast booting
+from Quad SPI flash devices.
+
+Usecase
+-------
+
+MLO/u-boot.img will be flashed from SD/MMC to the flash device
+using serial flash erase and write commands. Then, switch settings
+will be changed to qspi boot. Then, the ROM code will read MLO
+from the predefined location in the flash, where it was flashed and
+execute it after storing it in SDRAM. Then, the MLO will read
+u-boot.img from flash and execute it from SDRAM.
+
+SPI mode
+-------
+SPI mode uses mtd spi framework for transfer and reception of data.
+Can be used in:
+1. Normal mode: use single pin for transfers
+2. Dual Mode: use two pins for transfers.
+3. Quad mode: use four pin for transfer
+
+Memory mapped read mode
+-----------------------
+In this, SPI controller is configured using configuration port and then
+controler is switched to memory mapped port for data read.
+
+Driver
+------
+drivers/qspi/ti_qspi.c
+ - Newly created file which is responsible for configuring the
+ qspi controller and also for providing the low level api which
+ is responsible for transferring the datas from host controller
+ to flash device and vice versa.
+
+Testing
+-------
+A seperated file named README.dra_qspi_test has been created which gives all the
+details about the commands required to test qspi at u-boot level.
diff --git a/marvell/uboot/doc/SPI/status.txt b/marvell/uboot/doc/SPI/status.txt
new file mode 100644
index 0000000..13889f5
--- /dev/null
+++ b/marvell/uboot/doc/SPI/status.txt
@@ -0,0 +1,32 @@
+Status on SPI subsystem:
+=======================
+
+SPI COMMAND (common/cmd_sf, cmd_spi):
+-
+
+SPI FLASH (drivers/mtd/spi):
+- sf_probe.c: SPI flash probing code.
+- sf_ops.c: SPI flash operations code.
+- sf.c: SPI flash interface, which interacts controller driver.
+- Bank Address Register (Accessing flashes > 16Mbytes in 3-byte addressing)
+- Added memory_mapped support for read operations.
+- Common probe support for all supported flash vendors except, ramtron.
+- Extended read commands support(dual read, dual IO read)
+- Quad Page Program support.
+- Quad Read support(quad fast read, quad IO read)
+- Dual flash connection topology support(accessing two spi flash memories with single cs)
+- Banking support on dual flash connection topology.
+
+SPI DRIVERS (drivers/spi):
+-
+
+TODO:
+- Runtime detection of spi_flash params, SFDP(if possible)
+- Add support for multibus build/accessing.
+- Need proper cleanups on spi_flash and drivers.
+
+--
+Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
+18-09-2013.
+07-10-2013.
+08-01-2014.