3.1.1.7. OSPI/QSPI NOR/NAND

Introduction

Octal Serial Peripheral Interface (OSPI) and Quad Serial Peripheral Interface (QSPI) are SPI modules that have x8 IO lines and x4 IO lines respectively. These controllers are mainly used to interface with Octal and Quad SPI flashes. OSPI is backward compatible with QSPI. These modules can also work in dual (x2) and single (x1) modes. OSPI and QSPI controllers on TI SoCs support memory mapped IO interface, which provide a direct interface for accessing data from the external SPI flash, thereby simplifying software requirements. These controllers work only in master mode.

Note

Not all OSPI flashes can be supported. Users are recommended to check whether or not the OSPI flash part chosen for custom board designs meets all the criteria listed at https://e2e.ti.com/support/processors/f/791/t/946418

Driver Features

OSPI controllers supports PHY Calibration in DQS + Double Data Rate (DDR) mode for OSPI/QSPI NOR flashes in Octal configuration wherein data can be read on both edges of the clock, and non-DQS + Single Data Rate (SDR) mode for OSPI/QSPI NAND flashes in Quad and Octal configuration.

Memory mapped read support

Once the controller is configured in memory map mode, the whole flash memory is made available as a memory region at an SoC specific address. This region can be accessed using normal memcpy() (or mem-to-mem dma copy). Controller hardware will internally communicate with SPI flash over SPI bus and get the requested data. This mode provides the best throughput and is the default mode in the SDK.

Supported SPI modes

The cadence_qspi.c driver supports standard SPI mode 0 only.

DMA support

The driver uses mem-to-mem DMA copy on top of an OSPI/QSPI memory mapped port during flash read operations for maximum throughput and reduced CPU load.

The OSPI Controller does not support interfacing with non-flash SPI slaves.

Driver Configuration

Source Location

OSPI driver is at: drivers/spi/cadence_qspi.c under U-Boot source tree. This driver also supports QSPI version of the same IP.

DT Configuration

Flash properties:

  1. compatible: specifies the compatible string for the device, the operating system uses this string to identify and the match the driver for the device. Use ‘jedec,spi-nor’ for OSPI/QSPI NOR flashes and ‘spi-nand’ for OSPI/QSPI NAND flashes.

  2. spi-tx-bus-width and spi-rx-bus-width: specifies the bus width in bits for SPI transactions when transmitting (tx) and receiving (rx) data. Set for ‘8’ for OSPI flashes and ‘4’ for QSPI flashes.

  3. spi-max-frequency: defines the maximum frequency in Hertz at which the SPI bus can operate. Set 1/4th or 1/8th of ‘assigned-clocks’ value of ‘ospi0’ node for SDR and DDR mode respectively. If PHY Calibration is enabled, this value is ignored, and the maximum frequency is determined by the value specified in the ‘assigned-clocks’ property of ‘ospi0’ node.

  4. cdns,read-delay: specifies the delay in clock cycles between the fetch of a command and responding to that command by the flash devices. This differs with flashes, try with different read delays starting from 0 and find the minimum read-delay at which the flash driver probes correctly.

Note

The sf command is used to access SPI NOR flash, supporting read/write/erase and a few other functions. For more information on sf command in U-boot please refer to the u-boot documentation: here. And for accessing SPI NAND flash, the mtd command is used, supporting read/write/erase and bad block management.

Memory Layout of QSPI Flash

+----------------+ 0x00000
|      MLO       |
|                |
+----------------+ 0x040000
|   u-boot.img   |
|                |
+----------------+ 0x140000
|   DTB blob     |
+----------------+ 0x1c0000
|   u-boot env   |
+----------------+ 0x1d0000
|   u-boot env   |
|    (backup)    |
+----------------+ 0x1e0000
|                |
|     uImage     |
|                |
|                |
+----------------+ 0x9e0000
|                |
|  other data    |
|                |
+----------------+

Writing to QSPI from U-Boot

Note:

  • From the U-Boot build, the MLO and u-boot.img files are the ones to be written.

  • We load all files from an SD card in this example but they can just as easily be loaded via network (documented above) or other interface that exists.

Writing MLO and u-boot.img binaries.

For QSPI_1 build U-Boot with dra7xx_evm_config

U-Boot # mmc rescan
U-Boot # fatload mmc 0 ${loadaddr} MLO
U-Boot # sf probe 0
U-Boot # sf erase 0x00000 0x200000
U-Boot # sf write ${loadaddr} 0x00000 ${filesize}
U-Boot # fatload mmc 0 ${loadaddr} u-boot.img
U-Boot # sf write ${loadaddr} 0x40000 ${filesize}

change SW2[5:0] = 110110 for qspi boot.

For QSPI_4 build U-Boot with dra7xx_evm_qspiboot_config

U-Boot # mmc rescan
U-Boot # fatload mmc 0 ${loadaddr} MLO
U-Boot # sf probe 0
U-Boot # sf erase 0x00000 0x200000
U-Boot # sf write ${loadaddr} 0x00000 0x10000
U-Boot # fatload mmc 0 ${loadaddr} u-boot.img
U-Boot # sf write ${loadaddr} 0x40000 0x60000

change SW2[5:0] = 110111 for qspi boot.


Writing to QSPI using DFU

Setup: Connect the usb0 port of EVM to ubuntu host PC. Make sure dfu-util tool is installed.

#sudo apt-get install dfu-util

From u-boot:

U-Boot # env default -a
U-Boot # setenv dfu_alt_info ${dfu_alt_info_qspi}; dfu 0 sf "0:0:64000000:0"

From ubuntu PC: Using dfu-util utilities to flash the binares to QSPI flash.

# sudo dfu-util -l
(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc.
(C) 2010-2011 Tormod Volden (DfuSe support)
This program is Free Software and has ABSOLUTELY NO WARRANTY
dfu-util does currently only support DFU version 1.0
Found DFU: [0451:d022] devnum=0, cfg=1, intf=0, alt=0, name="MLO"
Found DFU: [0451:d022] devnum=0, cfg=1, intf=0, alt=1, name="u-boot.img"
Found DFU: [0451:d022] devnum=0, cfg=1, intf=0, alt=2, name="u-boot-spl-os"
Found DFU: [0451:d022] devnum=0, cfg=1, intf=0, alt=3, name="u-boot-env"
Found DFU: [0451:d022] devnum=0, cfg=1, intf=0, alt=4, name="u-boot-env.backup"
Found DFU: [0451:d022] devnum=0, cfg=1, intf=0, alt=5, name="kernel"

Flash the binaries to the respective regions using alternate interface number (alt=<x>).

# sudo dfu-util -c 1 -i 0 -a 0 -D MLO
# sudo dfu-util -c 1 -i 0 -a 1 -D u-boot.img
# sudo dfu-util -c 1 -i 0 -a 2 -D <DTB-file>
# sudo dfu-util -c 1 -i 0 -a 5 -D uImage

Booting from QSPI from u-boot

The default environment does not contain a QSPI boot command. The following example uses the partition table found in the kernel.

U-Boot # sf probe 0
U-Boot # sf read ${loadaddr} 0x1e0000 0x800000
U-Boot # sf read ${fdtaddr} 0x140000 0x80000
U-Boot # setenv bootargs console=${console} root=/dev/mtdblock19 rootfstype=jffs2
U-Boot # bootz ${loadaddr} - ${fdtaddr}

Booting from QSPI from SPL (Single stage or Falcon mode)

In this boot mode SPL (first stage bootloader) directly boots the Linux kernel. Optionally, in order to enter into U-Boot, reset the board while keeping ‘c’ key on the serial terminal pressed. When falcon mode is enabled in U-Boot build (usually enabled by default), MLO checks if there is a valid uImage present at a defined offset. If uImage is present, it is booted directly. If valid uImage is not found, MLO falls back to booting u-boot.img.

For QSPI single stage or Falcon mode, the CONFIG_QSPI_BOOT shall enabled.

Menuconfig->Bood media
   [ ] Support for booting from NAND flash
   ..
   [*] Support for booting from QSPI flash
   [ ] Support for booting from SATA
   ...

MLO, u-boot.img (optional), DTB, uImage are stored in QSPI flash memory. Refer the “Memory Layout” section for offset details. To flash binaries to QSPI, you can use DFU, for example.

The QSPI boot uses uImage. Build the kernel uImage. You will need to keep the U-Boot tool mkimage in your $PATH

# make uImage modules dtbs LOADADDR=80008000

If kernel is not build with CONFIG_CMDLINE to set correct bootargs, then add the needed bootargs in chosen node in DTB file, using fdtput host utility. For example, for DRA74x EVM:

# fdtput -v -t s arch/arm/boot/dts/dra7-evm.dtb "/chosen" bootargs "console=ttyO0,115200n8 root=<rootfs>"

Set the environment variable “boot_os” to 1.

From u-boot prompt

=> setenv boot_os 1
=> saveenv

Set the board boot from QSPI and reset the EVM. The SPL directly boots the kernel image from QSPI.