IMX reference manual based on linux5.15.5 — 4
Chapter 3 Storage
3.1 AHB-to-APBH Bridge with DMA (APBH-Bridge-DMA)
3.1.1 Overview
The AHB-to-APBH bridge provides the processor with an inexpensive peripheral connection bus running on AHB's HCLK. The H in APBH indicates that APBH is synchronized with HCLK.
The AHB-to-APBH bridge includes the AHB-to-APB PIO bridge for memory-mapped I/O to APB devices, as well as a central DMA facility for devices on this bus and a vectored interrupt controller for Arm cores . Each APB peripheral, including the Vectored Interrupt Controller, is documented in its own chapter elsewhere in this document.
These devices do not have a separate DMA bus. The contention between the use of the APBH bus by the DMA and the use of the APBH by the AHB-to-APB bridging function is mediated by internal arbitration logic. For contention between these two units, DMA takes precedence, and the AHB slave will report "not ready" via its HREADY output until the bridge transfer is complete. The arbiter keeps track of repeated locks and inverts priorities, ensuring that Arm platforms transmit on the APB every fourth time.
3.1.1.1 Hardware operation
The SDMA controller is responsible for transferring data between the MCU memory space and peripherals, and has the following characteristics.
• Multi-channel DMA supports up to 32 time-division multiplexed DMA channels
• Using 16-bit instruction set micro risc engine
• Each channel executes a specific script
• Fast context switching with preemptive multitasking based on two levels of priority
• 4kbytes ROM containing startup scripts (i.e. startup code) and other common utilities that can be referenced by scripts located in ram
• The 8kbyte RAM area is divided into a processor context area and a code space area for storing channel scripts downloaded from system memory.
3.1.1.2 Software Operation
DMA supports 16 channels of DMA services, as shown in the table below. Shared DMA resources allow each independent channel to follow a simple chain command list. The chain of command is established using a common structure.
Table 24. APBH DMA Channel Allocation
3.1.1.3 Source code structure
The following table shows the source files available in drivers/dma/
3.1.1.4 Menu Configuration Options
Enable the following modules in the menu configuration:
• Device Drivers > DMA Engine support > MXS DMA support.
3.1.1.5 Programming interface
This module implements the standard DMA API. See the API documentation located in the Linux documentation package for more information on the functions implemented in drivers such as the GPMI NAND driver.
3.2 EIM NOR
3.2.1 Introduction
EIM (External Interface Module) NOR driver supports parallel NOR flash.
3.2.2 Hardware Operation
By default, there is a parallel NOR on the i.MX 6Quad/6Dual SABER-AI board. Parallel NOR has more pins than SPI NOR.
On some boards, M29W256GL7AN6E is equipped. See the datasheet for details on parallel NOR.
3.2.3 Software operation
Similar to SPI NOR, Parallel NOR uses the MTD subsystem. Because parallel NOR is very small, you can just use jffs2, you can't use UBIFS for it.
3.2.4 Source code
3.2.5 Enable EIM NOR
Please refer to the DTS file to enable EIM NOR: mx6q-sabreauto-gpmi-weim.dts or imx6dl-sabreauto-gpmi-weim.dts.
3.3 MMC/SD/SDIO Host
3.3.1 Introduction
The MultiMediaCard (MMC)/ Secure Digital (SD)/ Secure Digital Input Output (SDIO) host driver implements a standard Linux driver interface to the ultra MMC/SD host controller (uSDHC).
Host drivers are part of the Linux kernel MMC framework.
The MMC driver has the following features:
• 1-bit or 4-bit operation for SD3.0 and SDIO 2.0 cards (so far we support SDIO v2.0 (AR6003 verified)).
• Support card detection.
• Support standard MMC commands.
• PIO and DMA data transfer.
• Support power management.
•Support 1/4 8-bit MMC card operation.
• For i.MX 6, USDHC supports eMMC4.4 SDR and DDR modes.
• For i.MX 7Dual, USDHC supports eMMC5.0, which includes HS400 and HS200.
• Support SD3.0 SDR50 and SDR104 modes.
3.3.2 Hardware operation
MMC communication is based on an advanced 11-pin serial bus designed to operate in the low voltage range. The uSDHC module supports MMC, and supports SD memory and I/O functions at the same time. uSDHC controls MMC, SD memory and I/O card, sends commands to the card, and performs data access to the card. The SD memory card system defines two optional communication protocols: SD and SPI. uSDHC only supports SD bus protocol.
The uSDHC Command Transfer Type and uSDHC Command Parameters registers allow issuing commands to the card. The uSDHC command register, system control register, and protocol control register allow the user to specify the format of data and responses, and control the read wait period.
There are four 32-bit registers used to store responses from the uSDHC card. uSDHC reads these four registers to get command response directly. uSDHC uses a fully configurable 128x32-bit FIFO for reading and writing. The buffer is used as temporary storage for data transferred between the host system and the card, and vice versa. The uSDHC data buffer access register bits hold 32 bits of data during read or write transfers.
The steps to receive data are as follows:
- When the number of words received in the buffer exceeds the number of words set in the RD_WML register, the uSDHC controller generates a DMA request
- When this request is received, the DMA engine starts transferring data from the uSDHC FIFO to the system memory by reading the data buffer access register.
The steps to transfer data are as follows: - Whenever the amount of buffer space exceeds the value set in the WR_WML register, the uSDHC controller generates a DMA request.
- After receiving this request, the DMA engine starts moving data from the system memory to the uSDHC FIFO by writing to the data buffer access register, fetching some predefined bytes.
The read-only uSDHC current status and interrupt status registers provide uSDHC operating status, application FIFO status, error conditions and interrupt status.
The module has the ability to generate interrupts and set corresponding status register bits when certain events occur.
The uSDHC Interrupt Status Enable Register and Signal Enable Register allow the user to control whether these interrupts occur.
3.3.3 Software operation
The Linux operating system contains an MMC bus driver, which implements the MMC bus protocol. The MMC block driver handles the file system read/write calls and sends commands to the uSDHC using the low-level MMC host controller interface driver.
The MMC driver is responsible for implementing the standard entry points for init, exit, request and set_ios. The driver implements the following functions:
uSDHC: initialization function esdhc_pltfm_init()Initialize the platform hardware and set platform-dependent flags or values to sdhci_host structure. •exit function esdhc_pltfm_exit()Deinitializes platform hardware and frees allocated memory. •function esdhc_pltfm_get_max_clock()Get the maximum supported by the platform SD Bus clock frequency. •function esdhc_pltfm_get_min_clock()Get the minimum supported by the platform SD Bus clock frequency. •esdhc_pltfm_get_ro()Get the read-only status of the card. •esdhc_execute_tuning()Handle tuning preparations. only use for SD3.0 UHS-I model. •esdhc_set_clock()Handles clock change requests.
The figure below shows how mmc related drivers are layered.
3.3.4 Drive characteristics
The MMC driver supports the following features:
• Supports multiple uSDHC modules.
• Provides all entry points for interfacing with the Linux MMC core driver.
• MMC and SD card.
• SDIO card.
• SD3.0 card.
• Identify data transmission errors such as command timeouts and CRC errors.
• Power management.
• It supports being built as a loadable or built-in module
3.3.5 Source code structure
The table below shows the uSDHC source files available in drivers/mmc/host.
3.3.6 Menu Configuration Options
This module provides the following Linux kernel configuration options.
•CONFIG_MMC build pair MMC Bus protocol support. exist menuconfig , this option is available under: — Device Drivers > MMC/SD/SDIO Card support —By default, this option is " Y". •CONFIG_MMC_BLOCK constructed a pair of MMC Block device driver support that can be used to mount filesystems. exist menuconfig , this option is available under: — Device Drivers > MMC/SD Card Support > MMC block device driver —By default, this option is " Y". •CONFIG_MMC_SDHCI_ESDHC_IMX for i.MX USDHC port. exist menuconfig , this option is below: — Device Drivers > MMC/SD Card Support > Secure Digital Host Controller Interface support > SDHCI support on the platform-specific bus > SDHCI platform support for the eSDHC i.MX controller will SDHCI The driver is compiled as a loadable module, several options should be selected as shown below: CONFIG_MMC_SDHCI=m，it can be found in Device Drivers > MMC/SD Card Support > Secure Digital Host Controller Interface support found in CONFIG_MMC_SDHCI_PLTFM=m，it can be found in Device Drivers > MMC/SD Card Support > Secure Digital Host Controller Interface support > SDHCI support on the platform-specific bus found on CONFIG_MMC_SDHCI_ESDHC_IMX=y，it can be found in Device Drivers > MMC/SD Card Support > Secure Digital Host Controller Interface support > SDHCI support on the platform-specific bus > SDHCI platform support for the Freescale eSDHC i.MX controller will SDHCI The driver is compiled as a built-in module, several options should be selected as shown below: CONFIG_MMC_SDHCI=y，it can be found in Device Drivers > MMC/SD Card Support > Secure Digital Host Controller Interface support found on CONFIG_MMC_SDHCI_PLTFM=y，it can be found in Device Drivers > MMC/SD Card Support > Secure Digital Host Controller Interface support > SDHCI support on the platform-specific bus found on CONFIG_MMC_SDHCI_ESDHC_IMX=y，it can be found in Device Drivers > MMC/SD Card Support > Secure Digital Host Controller Interface support > SDHCI support on the platform-specific bus > SDHCI platform support for the Freescale eSDHC i.MX controlle •CONFIG_MMC_UNSAFE_RESUME for use MMC/SD/SDIO Cards for embedded systems. exist menuconfig , this option is below:
3.3.7 Bind device tree
Required properties:
• compatible: should be "fsl,-esdhc"
reg: should contain the location of the eSDHC register
•interrupt: should contain eSDHC interrupt
Optional attributes:
•non-removable:Indicates that the card is permanently connected to the host •fsl, wp-internal:Indicates that the internal write protection of the controller is used •cd-gpios:specified for card detection GPIOs •wp-gpios:designated write-protected GPIOs •fsl, delay-line:for eMMC DDR mode specifies the delay line value
Example:usdhc@02194000 { /* uSDHC2 */
compatible = "fsl,imx6q-usdhc";
reg = <0x02194000 0x4000>;
interrupts = <0 23 0x04>;
clocks = <&clks 164>, <&clks 164>, <&clks 164>;
clock-names = "ipg", "ahb", "per";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc2_1>;
cd-gpios = <&gpio2 2 0>;
wp-gpios = <&gpio2 3 0>;
bus-width = <8>;
no-1-8-v;
keep-power-in-suspend;
enable-sdio-wakeup;
status = "okay";
};
refer to:
• Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
• arch/arm/boot/dts/imx6*.dtsi
3.3.8 Programming interface
This driver implements the functions required by the MMC bus protocol to interface with the i.MX uSDHC module. See the Linux documentation generated by build:make htmldocs.
3.3.9 Loadable Module Operation
SDHCI drivers can be built as loadable or built-in modules.
- How to build an SDHCI driver as a loadable module.
•CONFIG_MMC_SDHCI=m，it can be found in Device Drivers > MMC/SD Card Support > Secure Digital Host Controller Interface support found on •CONFIG_MMC_SDHCI_PLTFM=m，it can be found in Device Drivers > MMC/SD Card Support > Secure Digital Host Controller Interface support > SDHCI support on the platform-specific bus found on •CONFIG_MMC_SDHCI_ESDHC_IMX=y，it can be found in Device Drivers > MMC/SD Card Support > Secure Digital Host Controller Interface support > SDHCI support on the platform-specific bus > SDHCI platform support for the i.MX eSDHC i.MX controller found on
- How to load and unload SDHCI modules.
Due to dependencies, modules are loaded or unloaded in the module order as shown below.
The command to load the module is as follows:
• use insmod command to load the module, assuming it is sdhci.ko and sdhci-platform.ko exists in the current directory. $> insmod sdhci.ko $> insmod sdhci-platform.ko •pass modprobe command to load the module, make sure sdhci.ko and sdhci-platform.ko file exists in the corresponding kernel module lib Table of contents $> modprobe sdhci.ko $> modprobe sdhci-platform.ko The command to uninstall the module is as follows.: • pass rmsmod command uninstall. $> rmsmod sdhci-platform $> rmsmod sdhci • pass modprobe command to unload a module. $> modprobe -r sdhci-platform $> modprobe -r sdhci
3.4 NAND GPMI Flash
3.4.1 Introduction
MTD (NAND Flash Memory Technology Devices) driver for General Media Interface (GPMI) controllers
i.MX 6 series and i.MX 7Dual.
The NAND MTD driver will only function if the hardware-specific layers are implemented. Other functions, such as Flash read/write/erase, are handled automatically by the common layer provided by the Linux MTD subsystem for NAND devices.
The NAND MTD driver interfaces with the integrated NAND controller which supports file systems such as UBIFS, CRAMFS and JFFS2UBI and UBIFSCRAMFS and JFFS2. Since NAND Flash technology only supports block access, the driver implementation supports the lowest-level operations on external NAND Flash chips, such as block read, block write, and block erase. Because the blocks in NAND Flash cannot be guaranteed to be good, the NAND MTD driver can also detect bad blocks and pass this information to the upper layer to handle bad block management.
3.4.2 Hardware Operation
NAND flash memory is a non-volatile storage device used in embedded systems.
The driver does not support the case of random access memory, RAM or NOR flash. Reading and writing of NAND Flash must be done through GPMI. NAND Flash is a sequential access device suitable for mass storage applications. Code stored in NAND Flash cannot be executed from there. Code must be loaded into RAM memory and executed from there. i.MX 6 contains a hardware error correction module.
3.4.3 Software operation
mtd in Linux includes all memory devices such as RAM, ROM and different kinds of NOR/NAND flash memory.
The MTD subsystem provides unified access to all such devices. On top of the MTD device, the Flash File System (JFFS2) can be used for MTD block device emulation, or the UBI layer can be used. The UBI layer, in turn, can have a UBI filesystem on top of the volume, or a Flash Translation Layer (FTL) with a regular filesystem (FAT, Ext2/3) on top of it. Hardware-specific drivers interface with the GPMI module on i.MX 6. It implements the lowest level operations such as read, write and erase. If enabled, it also provides information about partitions on the NAND device—this information must be provided by platform code.
The NAND driver is the point at which read/write errors can be recovered if possible. Hardware error correction is performed by the BCH block and driven by the NAND driver code.
Detailed information on the NAND driver interface can be found at www.linux-mtd.infradead.org.
3.4.4 Basic operations: reading and writing
The NAND driver exports the following callbacks:
gpmi_ecc_read_page (ECC) gpmi_ecc_write_page (ECC) gpmi_read_byte (ECC) gpmi_read_buf (ECC) gpmi_write_buf (ECC) gpmi_ecc_read_oob (ECC) gpmi_ecc_write_oob (ECC)
Starting with kernel 4.1, the GPMI driver provides raw read/write mode, which exports these callbacks:
•gpmi_ecc_read_page_raw(No ECC) •gpmi_ecc_write_page_raw(none ECC) •gpmi_ecc_read_oob_raw(Without ECC) •gpmi_ecc_write_oob_raw(Without ECC)
These functions read the requested amount of data, with or without error correction. For read, call the gpmi_read_page() function, create the DMA chain, submit it for execution, and wait for completion. The writing situation is slightly more complicated: the data to be written is mapped and output by calling gpmi_send_page().
3.4.5 Backward Compatibility
Users should be aware of several major GPMI NAND driver changes in kernel 4.1 that may cause incompatible kernel upgrades.
• Export necessary information to userspace application via debugfs (kobs-ng)
• New BCH layout algorithm
• New raw read and write modes
In kernel 4.1, the NAND GPMI driver exports the necessary information to the upper layer via debugfs. The most common case is the NAND programming tool kobs-ng. If debugfs is not enabled, kobs-ng may not fully use new features, or may use inappropriate parameters. If debugfs is not enabled in custom kernel, then user needs to provide kobs-ng with correct BCH geometry information and raw access mode.
In previous cores, the BCH layout may not meet the minimum ECC requirements for NAND chips. Since Kernel 4.1, the BCH layout algorithm uses the ECC strength and step size required by NAND by default, and gets it from the ONFI parameter if it is accessible. This change may not be compatible with the BCH layout settings in the previous kernel. For backward compatibility, the kernel and U-boot provide switches using the traditional BCH layout.
• For Kernel, add "fsl,legacy-bch-geometry" to the device tree file.
• For U-Boot: Add "CONFIG_NAND_MXS_BCH_LEGACY_GEO" in the board configuration file.
For alignment, BCH legacy layout setting must be turned on/off in both kernel and U-boot.
Kobs-ng checks the kernel version or raw mode flags in debugfs to determine if the new raw mode is used to access the NAND chip. The new kobs-ng is fully backwards compatible with previous kernels, while older versions of kobs-ng will not work on kernel 4.1.
3.4.6 Error correction
When reading or writing data to Flash, some bits can be flipped. This is normal behavior and NAND drivers utilize various error correction schemes to correct it. It can be solved by software or hardware error correction. The GPMI driver only uses a hardware correction scheme with the help of the hardware accelerator bch.
For BCH, the page layout for 2K pages is (2K + 64), the page layout for 4K pages is (4K + 218), and the page layout for 8K pages is (8K + 448).
3.4.7 Start Control Block Management
During startup, the NAND driver scans the first block to determine if there is a NAND control block (NCB). Its presence is detected by a magic signature. When a signature is found, the boot block candidate is checked for errors using Hamming codes. If bugs are found, they are fixed where possible. If an NCB is found, it is parsed to retrieve the timing of the NAND chip.
All boot control blocks are created when the media is formatted with the userspace application kobs-ng.
3.4.8 Bad block processing
When the driver starts, by default, it builds a bad block table. Whether a block is bad can be determined dynamically, but for performance this is done at startup. Erase block defects are determined by checking the pattern in which the free area of each page of the block starts. But if the chip uses hardware error correction, the bad mark will fall into the ECC byte area. Therefore, if hardware error correction is used, the bad block marker should be moved.
3.4.9 Source code structure
The NAND driver is located in drivers/mtd/NAND/gpmi-nand.
The following table lists the source files of the NAND driver.
3.4.10 Menu Configuration Options
To enable the NAND driver, the following options must be set:
•Device Drivers > Memory Technology Device (MTD) support > GPMI NAND Flash Controller driver In addition, these MTD option must be enabled: •CONFIG_MTD_NAND = [y | m] •CONFIG_MTD = y •CONFIG_MTD_BLOCK = y Additionally, the following must be enabled UBI options: •CONFIG_MTD_UBI = y •CONFIG_UBIFS_FS = y
3.5 Quad Serial Peripheral Interface (QuadSPI)
3.5.1 Introduction
The Quad Serial Peripheral Interface (QuadSPI) block acts as an interface to one or two external serial flash devices with up to four bidirectional data lines per device.
The following features are supported:
•Flexible sequence engine, supporting devices of various flash manufacturers.
•Single, double, quad, octal operating modes.
• DDR/DTR mode, data is generated on each edge of the serial flash clock.
• Supports flash data strobe for data sampling in DDR and SDR modes.
• DMA supports reading RX buffer data through AMBA AHB bus (64-bit wide interface) or IP register space (32-bit access).
3.5.2 Hardware Operation
On some boards, it is equipped with Quad SPI NOR - N25Q256A, while on others, it is equipped with S25FL128S. Please check the Quad SPI NOR type on the board, and then configure it correctly.
The N25Q256A is a high-performance multiple-input/output serial flash memory device. Innovative, high-performance, dual and quad I/O instructions double or quadruple the transfer bandwidth for read and program operations. The memory is organized into 512 (64kb) main sectors, and 64kb sectors can be erased at a time. The device supports 3-byte or 4-byte address mode to access more than 128mb of memory. When 4-byte address mode is enabled, all commands requiring addresses must be entered and exited using the 4-byte address mode commands: Enter 4-byte address mode command and Exit 4-byte address mode command. 4-byte address mode can also be enabled through the nonvolatile configuration register. The memory can be operated using three different protocols: extended SPI (standard SPI protocol upgraded to dual and quad operation), dual input/output SPI, and quad input/output SPI. Each protocol has unique command to perform READ operation in DTR mode. This enables high data throughput while running at lower clock frequencies.
S25FL128S is a flash non-volatile storage product. It connects to the host system through the Serial Peripheral Interface (SPI).
Supports traditional SPI unit serial input and output (single I/O or SIO), and optional 2-bit (Dual I/O or DIO) and 4-bit (Quad I/O or QIO) serial commands. It also adds support for Double Data Rate (DDR) read commands for SIO, DIO, and QIO, which transfer addresses and read data on both ends of the clock.
3.5.3 Software operation
In a flash-based embedded Linux system, many Linux technologies work together to implement a file system. The following figure illustrates the relationship between some standard components.
The MTD subsystem of the Linux operating system is a general interface to memory devices (such as Flash and RAM), providing simple read, write, and erase access to physical memory devices. A device called mtdblock can be mounted by JFFS, JFFS2, and CRAMFS filesystems. The Quad SPI NOR MTD driver is based on the MTD data flash driver in the kernel, adding SPI access. In the initialization phase, the Quad SPI NOR MTD driver detects the data Flash by reading the JEDEC ID. The driver adds MTD devices. The SPI NOR MTD driver also provides an interface for reading, writing and erasing NOR Flash.
3.5.4 Drive characteristics
This Quad NOR driver implementation supports the following features:
• Information required by upper layer MTD drivers.
3.5.5 Source code structure
3.5.6 Menu Configuration Options
To enable the Quad SPI driver, the following options must be set:
Device Drivers >Memory Technology Device (MTD) support > Freescale Quad SPI controller
For configuration, set these to enable Quad Spi.
•CONFIG_MTD_SPI_NOR: SPI NOR frame, which can be SPI device drivers and SPI-NOR used by device drivers. •CONFIG_SPI_FSL_QUADSPI:Enable the pair in master mode quadspi Controller support.
3.6 SATA
3.6.1 Introduction
The SATA AHCI driver is based on the LIBATA layer of the Linux kernel's block device infrastructure. The detailed hardware operation of SATA is described in detail in the Synopsys DesignWare Cores SATA AHCI document, which is named SATA_Data_Book.pdf.
3.6.2 Board Configuration Options
Power off, install SATA cables and hard drives.
3.6.3 Software operation
See the libata Developer's Guide for details on the libata api.
The SATA AHCI driver is based on the LIBATA layer of the Linux kernel's block device infrastructure. The i.MX integrated AHCI linux driver in conjunction with the standard AHCI driver handles the details of the integrated i.MX SATA AHCI controller, while the LIBATA layer understands and executes the SATA protocol. SATA devices (such as hard disks) are exposed to applications in user space through the /dev/sda* interface. File systems are built on block devices. AHCI specifies the integrated DMA engine which assists the SATA controller hardware in DMA transfer mode.
3.6.4 Source code structure
Standard AHCI and AHCI platform drivers are used to do actual SATA operations.
3.6.5 Menu Configuration Options
The Linux kernel configuration provided by the SATA driver is as follows:
Symbol: AHCI_IMX [=y] Type : tristate Prompt: Freescale i.MX AHCI SATA support Location: -> Device Drivers -> Serial ATA and Parallel ATA drivers (ATA [=y]) -> Platform AHCI SATA support (SATA_AHCI_PLATFORM [=y])
In busybox, enable "fdisk" under "Linux System Utilities".
3.6.6 Programming interface
The API for the SATA driver is the standard POSIX device interface (eg: open, close, read, write, and ioctl) on /dev/sda*.
3.6.7 Example usage
Please note:
When initializing a small number of SATA disks, there may be a known error message such as:
ata1.00: serial number mismatch '090311PB0300QKG3TB1A' != "
Ata1.00: Reauthentication failed (errno= 19)
This point should be ignored.
- After building the kernel and SATA AHCI drivers and deploying them, boot the target and log in as root.
- Make sure AHCI and AHCI platform drivers are built in or loaded into the kernel.
You should see a message similar to the following:
ahci: SSS flag set, parallel bus scan disabled ahci ahci: AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl platform mode ahci ahci: flags: ncq sntf stag pm led clo only pmp pio slum part ccc apst scsi0 : ahci_platform ata1: SATA max UDMA/133 mmio [mem 0x02200000-0x02203fff] port 0x100 irq 71 ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata1.00: ATA-8: SAMSUNG HM100UI, 2AM10001, max UDMA/133 ata1.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32) ata1.00: configured for UDMA/133 scsi 0:0:0:0: Direct-Access ATA SAMSUNG HM100UI 2AM1 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) sd 0:0:0:0: [sda] 4096-byte physical blocks sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sd 0:0:0:0: [sda] Attached SCSI disk
You can use standard Linux utilities to partition and create filesystems on drives mounted and used by applications (eg: fdisk and mke2fs).
Device nodes for drives and their partitions appear under /dev/sda*. For example, to check a drive's basic kernel settings, execute hdparm /dev/sda.
3.6.8 Example usage
create partition
You can use the following command to query the capacity of the hard disk. If the drive is pre-formatted, this command will display the drive's size, partitions, and filesystem type:
$fdisk -l /dev/sda
If the hard disk is not formatted, use the following command to create partitions on the hard disk:
$fdisk /dev/sda
After partitioning, files like /dev/sda[1-4] are created.
Block read and write test: The dd command is used to read and write blocks. Note that this command will destroy partitions and filesystems on the hard disk.
To clear the first 5 KB of the card:
$dd if=/dev/zero of=/dev/sda1 bs=1024 count=5
The answer should be as follows:
5+0 records in 5+0 records out
To write the contents of a file to the card, enter the following text, replacing filename with the filename you want to write, do the following:
$dd if=file_name of=/dev/sda1
To read 1KB of data from the card, enter the following text, substituting output_file for the name of the file to write, and proceed as follows:
$dd if=/dev/sda1 of=output_file bs=1024 count=1
file system test
Format the hard disk partition with mkfs.vfat or mkfs.ext2, depending on the file system:
$mkfs.ext2 /dev/sda1 $mkfs.vfat /dev/sda1
The way to mount the file system is as follows:
$mkdir /mnt/sda1 $mount -t ext2 /dev/sda1 /mnt/sda1
After the mount is complete, you can operate in the "/mnt/sda1" directory.
The steps to unmount a file system are as follows:
$umount /mnt/sda1