ufs_device.hh File Reference

This is a base class for UFS devices The UFS interface consists out of one host controller which connects a number of devices which together contain up to 8 logic units. More...

#include <deque>
#include "base/addr_range.hh"
#include "base/bitfield.hh"
#include "base/statistics.hh"
#include "debug/UFSHostDevice.hh"
#include "dev/arm/abstract_nvm.hh"
#include "dev/arm/base_gic.hh"
#include "dev/storage/disk_image.hh"
#include "dev/dma_device.hh"
#include "dev/io_device.hh"
#include "mem/packet.hh"
#include "mem/packet_access.hh"
#include "params/UFSHostDevice.hh"
#include "sim/serialize.hh"
#include "sim/stats.hh"

Go to the source code of this file.

Classes
class	UFSHostDevice
	UFS command flow state machine digraph CommandFlow{ node [fontsize=10]; IDLE -> transferHandler [ label=" transfer/task/command request " fontsize=6]; transferHandler -> command [ label=" It is a command " fontsize=6]; command -> IDLE [ label=" Command done, no further action " fontsize=6]; transferHandler -> taskStart [ label=" It is a task " fontsize=6]; taskStart -> finalUTP [ label=" Task handled, now acknowledge (UFS) " fontsize=6]; transferHandler -> transferStart [ label=" It is a transfer " fontsize=6]; transferStart -> SCSIResume [ label=" Transfer, obtain the specific command " fontsize=6]; SCSIResume -> DiskDataFlowPhase [ label=" Disk data transfer (see other graphs) " fontsize=6]; SCSIResume -> DeviceDataPhase [ label=" Device info transfer (handled in SCSIResume) " fontsize=6]; DiskDataFlowPhase -> transferDone [ label=" Transfer done, acknowledge SCSI command " fontsize=6]; DeviceDataPhase -> transferDone [ label=" Transfer done, acknowledge SCSI command " fontsize=6]; transferDone -> finalUTP [ label=" Transfer handled, now acknowledge (UFS) " fontsize=6]; finalUTP -> readDone [ label=" All handled, clear data structures " fontsize=6]; readDone -> IDLE [ label=" All handled, nothing outstanding " fontsize=6]; readDone -> transferHandler [ label=" All handled, handle next outstanding " fontsize=6]; }. More...
struct	UFSHostDevice::HCIMem
	Host Controller Interface This is a set of registers that allow the driver to control the transactions to the flash devices. More...
struct	UFSHostDevice::UTPUPIUHeader
	All the data structures are defined in the UFS standard This standard be found at the JEDEC website free of charge (login required): http://www.jedec.org/standards-documents/results/jesd220. More...
struct	UFSHostDevice::UTPUPIURSP
	struct UTPUPIURSP - Response UPIU structure header: UPIU header DW-0 to DW-2 residualTransferCount: Residual transfer count DW-3 reserved: Reserved DW-4 to DW-7 senseDataLen: Sense data length DW-8 U16 senseData: Sense data field DW-8 to DW-12 More...
struct	UFSHostDevice::UTPUPIUTaskReq
	struct UTPUPIUTaskReq - Task request UPIU structure header - UPIU header structure DW0 to DW-2 inputParam1: Input param 1 DW-3 inputParam2: Input param 2 DW-4 inputParam3: Input param 3 DW-5 reserved: Reserver DW-6 to DW-7 More...
struct	UFSHostDevice::UFSHCDSGEntry
	struct UFSHCDSGEntry - UFSHCI PRD Entry baseAddr: Lower 32bit physical address DW-0 upperAddr: Upper 32bit physical address DW-1 reserved: Reserved for future use DW-2 size: size of physical segment DW-3 More...
struct	UFSHostDevice::UTPTransferCMDDesc
	struct UTPTransferCMDDesc - UFS Commad Descriptor structure commandUPIU: Command UPIU Frame address responseUPIU: Response UPIU Frame address PRDTable: Physcial Region Descriptor All lengths as defined by JEDEC220 More...
struct	UFSHostDevice::UPIUMessage
	UPIU tranfer message. More...
struct	UFSHostDevice::UTPTransferReqDesc
	struct UTPTransferReqDesc - UTRD structure header: UTRD header DW-0 to DW-3 commandDescBaseAddrLo: UCD base address low DW-4 commandDescBaseAddrHi: UCD base address high DW-5 responseUPIULength: response UPIU length DW-6 responseUPIUOffset: response UPIU offset DW-6 PRDTableLength: Physical region descriptor length DW-7 PRDTableOffset: Physical region descriptor offset DW-7 More...
struct	UFSHostDevice::UTPTransferReqDesc::RequestDescHeader
	struct RequestDescHeader dword0: Descriptor Header DW0 dword1: Descriptor Header DW1 dword2: Descriptor Header DW2 dword3: Descriptor Header DW3 More...
struct	UFSHostDevice::SCSIReply
	SCSI reply structure. More...
struct	UFSHostDevice::LUNInfo
	Logic unit information structure. More...
struct	UFSHostDevice::transferInfo
	Different events, and scenarios require different types of information. More...
struct	UFSHostDevice::transferDoneInfo
	transfer completion info. More...
struct	UFSHostDevice::transferStart
	Transfer start information. More...
struct	UFSHostDevice::taskStart
	Task start information. More...
struct	UFSHostDevice::SCSIResumeInfo
	After a SCSI command has been identified, the SCSI resume function will handle it. More...
struct	UFSHostDevice::writeToDiskBurst
	Disk transfer burst information. More...
struct	UFSHostDevice::UFSHostDeviceStats
	Statistics. More...
class	UFSHostDevice::UFSSCSIDevice
	device layer: This is your Logic unit This layer implements the SCSI functionality of the UFS Device One logic unit controls one or more disk partitions More...

Detailed Description

This is a base class for UFS devices The UFS interface consists out of one host controller which connects a number of devices which together contain up to 8 logic units.

A Logical Unit is an externally addressable, independent, processing entity that processes SCSI tasks (commands) and performs task management functions. The decision has been made to abstract the device away, and model the different logic units. Effectively this means that there is one Host layer which handles all the UFS commands (everything UTP, UPIU and UNIpro related) and a SCSI layer, which handles the SCSI interpretation and the interaction with the "disk" (effectively the LBA that that particular Logic Unit controls). Each Logic unit should therefor control a disk image and a timing model. The UFS protocol has three types of commands (explained later). Each has different phases and each phase need to wait for its particular data. This is the reason that this model contains a lot of events. For clarity, a state diagram in doxygen has been provided. To fully apreciate the stages that the model flows through, the states have been broken into three state diagrams. It is best if one imagines the command flow state machine to be happening in the UFSHost layer, and the other two to flow through all the layers of the model (UFS host, SCSI and NVM model). See it as a quarry, one state diagram is moving the crane into place, and the other ones are transporting the dirt down, or the valuables up. For complete information about the working of UFS please refer to http://www.jedec.org/standards-documents/results/jesd220 or http://www.jedec.org/standards-documents/results/jesd223 The documents are available free of charge, although you will need to have an acount.

Definition in file ufs_device.hh.