BSP.pptx

ROBOT OPERATING SYSTEM
Department of Robotics & Automation
JSS Academy of Technical Education, Bangalore-560060
(Course Code: 21RA54)

ROS
MODULE 3: BOARD SUPPORT PACKAGES (BSP)

Books
Text Books:
Embedded Linux system design and development, P. Raghavan, Amol Lad, Sriram Neelakandan,
Auerbach Publications, 2006

Course outcomes (Course Skill Set)
CO3: Configure BSPs for specific hardware platforms, integrate device drivers and
optimize BSPs for performance and resource utilization.
At the end of the course, students will be able to,

Continuous Internal Evaluation (CIE)
• Three IA Tests, each of 20 Marks
• Two assignments each of 20 Marks
• The sum of three tests, two assignments, will be out of 100 marks and will be scaled
down to 50 marks
The minimum passing mark for the CIE is 40% of the maximum marks (20 marks out of 50)

Inserting BSP in Kernel Build Procedure, Boot loader Interface, Memory Map,
Interrupt Management, PCI Subsystem: Timers - UART- Power Management.
Embedded Storage: MTD, MTD Architecture - MTD Driver for NOR Flash - Flash
Mapping Driver
Content

Introduction
• In embedded systems, a board support package (BSP) is the software layer containing hardware-specific
boot firmware and device drivers and other routines that allow a given embedded operating system, (RTOS),
to function in a given hardware environment (a motherboard),
• Integrated with the embedded operating system.
• BSP contains essential software a Computer hardware device needs to work with the computer’s Operating
System (OS). Whenever the hardware device is switched off, the bootloader or boot manager on the BSP will
ensure the OS and device drivers are placed into memory.

Introduction
• A BSP is used to start up and run the embedded target processor.
• The BSP support a minimum number of peripherals on an eval board;
so that the user can at least demonstrate that SoC peripherals work
and that the SoC can be easily programmed to carry out the main
features.
• The BSP has a boot-up program called the “bootloader” or a boot
manager, and there are different BSPs for different operating systems.
• BSP contains drivers that enable the peripherals to communicate with
the operating system.
• The BSP provides a file structure and will initialize several systems,
including the processor, any communication buses, clocks, and
memory, as well as start up the boot loader.

Introduction
The BSP has two components;
1. The microprocessor support: Linux has wide support for all the leading processors in the embedded
market such as MIPS (Microprocessor without Interlocked Pipelined Stages), ARM (Advanced RISC
Machine), and PowerPC.
2. The board-specific routines: A typical HAL for the board hardware will include:
1. Bootloader support
2. Memory map support
3. System timers
4. Interrupt controller support
5. Real-Time Clock (RTC)
6. Serial support (debug and console)
7. Bus support (PCI/ISA)
8. DMA support
9. Power management

Inserting BSP in Kernel Build Procedure
The Linux HAL source code resides under arch/ and include/<asm-XXX> directories
(XXX = processor name such as PowerPC, MIPS, ARM).
• arch/ppc will contain the source files for the PPC-based board
• include/asm-ppc will contain the header files.
• Under each processor directory, all boards based on that CPU are categorized again into subdirectories.
The important directories under each subdirectory are:
1. Kernel: This directory contains the CPU-specific routines for initializing, IRQ (interrupt request) set-up,
interrupts, and traps routines.
2. mm: Contains the hardware-specific TLB (translation lookaside buffer) set-up and exception-handling code.

Example: MIPS HAL
• It has the two subdirectories arch/mips/kernel and arch/mips/mm that hold the above code.
• Along with these two directories, there is a host of other subdirectories; these are the BSP directories that hold
• the board-specific code only.
• The user needs to create a subdirectory tree under the appropriate processor directory that contains the files
necessary for the BSP.
• The next step is to integrate the BSP with the build process so that the board-specific files can be chosen
when the kernel image is built.

• The above two steps can be accomplished by hooking the BSP with the configuration process.
• Linux kernel components are selected using the make config (or the make menuconfig/make xconfig)
command.
• Heart of the configuration process is the configuration file placed under the specific processor
directory.

Boot loader Interface
• The boot loader is a software that starts executing immediately after the system is powered on.
• Boot-loading issues are specific to the CPU and the boards.
• Many CPUs, such as the ARM, x86, and MIPS, start execution at specific vectors at reset.
• Some others, such as M68K, fetch the starting location from a boot ROM.
• Eliminating the boot loader and flashing the kernel that bootstraps itself is an approach provided by many
RTOSs, which provides boot initialization routines to do POST, set up chip selects, initialize RAM and
memory caches, and transfer the image from ROM to RAM.
• Most of the reset initialization is board-specific, and manufacturers of boards give an onboard PROM that
does the above.

The mandatory boot loader functionalities are:
1. Initializing the hardware: processor, memory controller, and the hardware devices necessary for loading
the kernel such as flash.
2. Loading the kernel: The necessary software to download the kernel and copy it to the appropriate
memory location

• The following is the list of steps (generic) that any boot loader normally follows;
• X86 processors normally are shipped with an onboard BIOS that helps with the basic power-on and
loading a secondary boot loader for loading the OS ; hence the following set of steps is meant for the
non-X86 processors such as MIPS and ARM.

• Most boot loaders start from the flash.
• They do the processor initialization such as configuring the cache, setting up some basic registers,
and verifying the onboard RAM.
• Run the POST routines to do validation of the hardware required for the boot procedure such as
validating memory, flash, buses, and so on.
1. Booting
• The boot loaders relocate themselves to the RAM.
• This is because RAM is faster than flash.
• The relocation step include decompression, as the boot loaders are kept in a compressed format to
save storage space.
2. Relocation

• The boot loader initializes the basic devices necessary for user interaction. (console that a UI is
shown for the user).
• It also initializes the devices necessary for picking up the kernel (and maybe the root file system).
• This may include the flash, network card, USB, and so on.
3. Device initialization
• UI is shown for the user to select the kernel image to download onto the target
• There can be a deadline set for the user to enter choice.
• In case of a timeout a default image can be downloaded
4. UI

• The kernel image is downloaded.
• In case the user has given the choice to download a root file system using the initrd mechanism, the
initrd image too gets downloaded to memory
5. Image download
• In case arguments need to be passed to the kernel, the command-line arguments are filled and
placed at known locations to the Linux kernel.
6. Preparing kernel boot
7. Booting kernel
• The transfer is given to the kernel.
• Once the Linux kernel starts running, the boot loader is no longer necessary.

Bootloader start-up
sequence

Criteria in choosing a boot loader for a given embedded platform
1. Support for the embedded hardware
2. Licensing issues
3. Storage footprint: Bootloaders support compression to save flash space.
4. Support for network booting: Boot loaders support booting via the network. (protocols BOOTP, DHCP, and TFTP)
5. Support for flash booting: Flash booting has two components, flash reader software and file system reader
software
6. Console UI: Gives the user the following choices. – Choosing the kernel image and location, – Setting the mode
of kernel download (network, serial, flash), – Configuring the arguments to be passed to the kernel
7. Upgrade solutions: requires a flash erase and flash writing software in the boot loader.

Memory Map
• It defines the layout of the CPU’s addressable space.
• It defines which hardware resides at which of the processor's addresses. Hardware may be RAM, ROM,
Flash, serial ports, parallel ports, timers, interrupt vectors, etc., addressable by the processor..
• Memory map is managed by means of linker scripts or linker command files.
• It maps resources like Flash or Internal RAM (L1P, L1D, L2, L3) or External RAM(DDR) or ROM or
peripherals (ports, serial, parallel, USB etc) or specific device registers or I/O ports with appropriate fixed
addresses in the memory space of the system.

Memory Map
• It freezes on the address space allocated for various hardware components such as RAM, flash, and
memory-mapped IO peripherals.
• It highlights the allocation of onboard memory to various software components, such as the bootloader
and the kernel.
• It defines the virtual-to-physical address mapping for the board.
The memory map is needed for the following reasons.

Memory Map
There are three addresses that are seen on an embedded Linux system
1. CPU untranslated or physical address: The address that is seen on the actual memory bus.
2. CPU-translated address or virtual address: The address range recognized by the CPU as the valid address
range.
3. Bus address: This is the address of memory as seen by devices other than the CPU.

Memory Map
Defining the memory map requires the following understanding
• Understanding the memory and IO addressing of the hardware components on the board. (often
requires an understanding of how the memory and IO bus controllers are configured).
• Understanding how the CPU handles memory management.

Memory Map
Steps in the creation of the memory map for the system
1. The processor memory map: This is the first memory map to be created.
• It explains the CPU’s memory management policies such as how the CPU
handles the different address spaces (user mode, kernel mode),
• What are the caching policies for the various memory regions.
2. The board memory map: Fit the various onboard devices into the processor
memory areas.
• (requires an understanding of the various onboard devices and the bus
controllers).
3. The software memory map: A portion of the memory needs to be given for the
various software components such as the bootloader and the Linux kernel.
• The Linux kernel sets up its memory map and decides where the various
kernel sections, such as code and heap, will reside.
Memory layout for the first 4 gigabytes in an Intel system

Interrupt Management
Every board is unique with its hardware interrupt management, because of the PIC (Programmable Interrupt
Controller) interface.
Basic functionalities of a PIC
1. A microprocessor has a limited number of interrupts.
• This may be a limitation if there are many devices on board, and all of these need to interrupt the
processor.
• The interrupt controller will help in such a case. By allowing many interrupts to be multiplexed over a single
interrupt line, it expands the interrupt capability of the processor.

2. PIC provides hardware priority for interrupts.
• Useful in case the processor does not support hardware interrupt priority.
• When the processor handles an interrupt of a higher priority, the PIC does not deliver a lower-priority
interrupt to the processor.
• When two devices interrupt simultaneously, the PIC will look at a priority register to recognize the higher-
priority interrupt and then deliver it to the CPU.

3. To do trigger conversions.
Hardware delivers interrupts in two ways: level and edge trigger.
• Edge-triggered interrupts happen on the transition of a signal from one state to another (from high to low);
• It is a short pulse that indicates the occurrence of an interrupt & they do not allow interrupt sharing
• Level-triggered interrupts: hold the interrupt line high until the processor turns it off.
• Edge-triggered interrupts are an older method of interrupts, used by the ISA bus architectures.
• Level triggers allow interrupt sharing but have to be used carefully, an improperly designed interrupt
handler can cause the system to be stuck forever in the interrupt loop.

PCI Subsystem
Peripheral Component Interconnect (PCI)
• Peripheral Component Interconnect, commonly known as PCI, is a local computer bus standard that
connects hardware devices to the CPU and motherboard.
• The PCI standard has undergone several revisions, with PCI, PCI-X, and PCI Express (PCIe) being the
most notable.
• Understanding and managing the PCI subsystem are essential for system designers, hardware engineers,
and software developers working with PCI-based systems.
• This includes configuring PCI devices, handling interrupts, implementing device drivers, and ensuring
proper communication between the operating system and the connected hardware components.

PCI Subsystem
• Linux assumes that the BIOS or the firmware is responsible for configuring every PCI device
• When a device driver accesses the device, its memory and IO regions should be mapped to the processor’s
address space.
• Many boards do not come with a BIOS or firmware that does PCI initialization.
• Even if it does, the address range offered to the devices may not exactly meet Linux requirements.
• Hence, it is the responsibility of the BSP to do the probing and configuration of the PCI devices.

PCI Subsystem
1. Memory Map Issues
2. Configuration Space Access
3. Interrupt Routing on the Board
Uniqueness of PCI Architecture

PCI Subsystem
1. Memory Map Issues
• The piece of hardware that connects the processor bus to the PCI bus is called the north bridge.
• The north bridge has a memory controller built in so that it can access the processor’s memory.
• Some north bridges have the capability to make the PCI device address space part of the processor’s
address space; they do this by trapping the addresses on the processor’s bus and issuing PCI read/write
cycles.

PCI Subsystem
2. Configuration Space Access
• Every PCI device has a configuration space that needs to be read and programmed before the device can
actually be used.
• The processor does not have direct access to the configuration space but is dependent on the PCI controller
for this.
• The PCI controller provides registers, which need to be programmed for doing device configuration as this is
board-dependent; the BSP must provide for these routines.

PCI Subsystem
3. Interrupt Routing on the Board
PCI hardware provides four logical interrupts, A, B, C, and D, to be hardcoded in every PCI device.
This information is stored in the interrupt pin field in the configuration header.
The configuration space has another field called the interrupt line, which needs to be filled with the
actual interrupt line that the PCI device uses.
The BSP needs to scan the configuration header for the interrupt pin information and then, from the interrupt
routing map, fill the interrupt line field.

PCI Software Architecture
The PCI software architecture can be divided into four layers for MIPS.
1. BSP: The BSP gives the following information to the software.
– The IO base for accessing the PCI memory and IO regions
– The routines to access the PCI configuration space
– The interrupt routing map on the board

2. HAL: This layer implements the BIOS functionality of assigning the PCI resources (memory and IO) to
the various devices.
• The HAL uses the information given by the BSP to assign resources.
• The HAL support includes functions for scanning the bus, building the PCI device tree, and resource
management.

3. PCI library:
• It provides APIs for the HAL and the device drivers.
• The library is located in the kernel source under the directory drivers/pci
4. PCI device drivers: They make use of the functions exported by the PCI library.

Timers
There are two timers that need to be programmed by the BSP
1. The Programmable Interval Timer (PIT): This timer is hooked to the timer interrupt that provides the
system pulse or ticks.
2. The Real-Time Clock (RTC) is an independent processor, as it is an external chip on the board.
• The RTC is operated by a special battery that powers it even when the board is switched off; thus, once
programmed, it can provide the time of day services.
• The first timer is mandatory on any Linux system; the RTC on the other hand is not mandatory.

• UART stands for Universal Asynchronous Receiver/Transmitter.
• It's a hardware component (often integrated into microcontrollers or as a separate IC) used for serial
communication.
• The "universal" aspect refers to its versatility in being able to handle various communication protocols, baud
rates, and data formats.
• "Asynchronous" means that data is transmitted without a shared clock signal between the sender and
receiver. Instead, both sides agree on a baud rate, and the UART synchronizes based on the timing of the
start and stop bits in each transmitted byte.
• UARTs are commonly used for communication between microcontrollers, sensors, displays, and other
peripheral devices. Also frequently used in debugging and programming interfaces, especially during the
development of embedded systems.
UART

• UART stands for universal asynchronous receiver/transmitter and defines a protocol, or set of rules, for
exchanging serial data between two devices.
UART
The serial port on the board can be used for three purposes
1. The system console for displaying all the boot messages
2. Standard TTY (teletypewriter) device
3. The kernel debugger KGDB interface
TTY is a common term used to describe serial communication devices, in Unix-like operating systems. These serial ports can be used for
connecting to external devices, communication between different components of a system, debugging etc.

Power Management
• Many embedded devices have different power requirements depending on their usage.
• The APM (Advanced Power Management) and the ACPI (Advanced Configuration and Power Interface)
standard.
• For example, network routers need to have minimal energy consumption to avoid heating, especially
under rugged conditions.
• Devices such as PDAs and cell phones need to consume less energy so that battery life is not cut short.

Hardware and Power Management
Power Management
• To understand how an embedded system consumes power, find out the power consumption of the various
hardware devices constituting it.
Consider a handheld device that consists of the following components.
1. A processor
2. Memory (both DRAM and flash memory)
3. A network card
4. A sound card
5. An LCD-based display unit

Power Management
The OS plays an important role in implementing the power management framework.
1. It makes decisions as to when the processor can go into various modes such as idle mode and sleep
mode. Also the appropriate wake-up mechanisms need to be devised by the OS.
2. Provides support for dynamically scaling the frequency and voltage depending on the system load
3. Provides a driver framework, various device drivers can be written to exploit the power-saving modes of
the peripherals
4. Exports the power management framework to specific applications

Power Management
OS needs to consider the following factors to use the sleep mode.
1. The state of the system, such as the CPU and the peripherals, needs to be saved in memory so that the
saved context can be restored when the system returns from sleep condition.
2. The time to come out of the sleep state should be fast so that real-time characteristics of the system are met
3. The events that need to awaken the system must be evaluated and incorporated into the software.
4. Keeping track of the time when the system goes to sleep is a very tricky part. The system should not lose
track of the time when going to sleep, the system should also consider the fact that there may be tasks that
are sleeping and need to be awakened after the system goes to sleep.

Embedded Storage
• Traditional storage on embedded systems was done using a ROM for storage of read-only code and a
NVRAM (Non Volatile RAM) for storage for the read-write data.
• They were replaced by flash technology, which provides high-density nonvolatile storage.
• These advantages combined with the low cost of flash have increased their usage in embedded systems
• Latest trend is flash technology devices
• More commonly referred as MTD
• Comes as NOR, NAND varieties
• Best suited for Embedded Systems

Flash Map
On an embedded Linux system, a flash will be used for:
1. Storing the boot loader
2. Storing the OS image
3. Storing the applications and application library images
4. Storing the read-write files (having configuration data)
The first three are read-only for most of the system execution time (except at upgrade times).
Flash map for 4-MB
flash.

Flash Map
The flash map outlines how the available flash memory is partitioned or segmented for storing different types of
data such as:
1. Bootloader:
• This is the initial code that executes when the system is powered on or reset.
• The bootloader often resides in a specific portion of flash memory
• Responsible for loading the main application code into RAM or directly executing it.
2. Application Code:
• This is the main program code that the embedded system runs.
• It occupies a portion of flash memory separate from the bootloader.
• The flash map defines the start address and size of the area reserved for storing the application code.

Flash Map
3. Configuration Data:
• Some embedded systems store configuration settings in flash memory.
• These could include calibration values, user preferences, or device settings.
• The flash map specifies where in flash memory this data is stored.
4. Firmware Updates:
• A portion of flash memory may be reserved for storing new firmware images.
• This allows the system to update its software without requiring additional external memory.
5. File System (if applicable):
• In systems that require file storage, such as running embedded Linux or other OS, a portion of flash
memory may be allocated for a file system.
• This enables the system to read from and write to files stored in flash memory.

MTD—Memory Technology Device
• The Memory Technology Devices (MTD) subsystem in Linux is responsible for abstracting and managing
various types of flash memory devices.
• These include both NOR flash (used for storage) and NAND flash (often used for storage and system
booting in embedded devices).
• The MTD subsystem provides a uniform interface for accessing these devices, regardless of the flash
memory technology.

What are the differences between flash devices and block drives?
The following table describes the differences between block devices and raw flashes.
Note: SSD, MMC, eMMC, RS-MMC, SD, mini-SD, micro-SD, USB flash drive, CompactFlash, MemoryStick,
MemoryStick Micro, and other FTL (Flash Translation Layer) devices, hard drives are block devices, not raw
flash devices.
Block device MTD device
Consists of sectors Consists of eraseblocks
Sectors are small (512, 1024 bytes) Eraseblocks are larger (typically 128KiB)
Maintains 2 main operations: read sector and write sector
Maintains 3 main operations: read from eraseblock, write to
eraseblock, and erase eraseblock
Bad sectors are re-mapped and hidden by hardware
(in modern LBA(Logical block addressing) hard drives.
Bad eraseblocks are not hidden and should be dealt with in
software
Sectors are devoid of the wear-out property
(in FTL devices it is the responsibility of FTL to provide this)
Eraseblocks wear-out and become bad and unusable after
about 103 (for MLC NAND) - 105 (NOR, SLC NAND) era

Flash Chips
• Flash devices come in two types: NAND and NOR flash.
• (NOR was introduced by Intel and NAND by Toshiba in the late 1980s)
• When embedded systems evolved to have large storage (media players and digital cameras), NAND flash
became popular for data storage applications.
• NOR chips come in two types: older non-CFI chips and the newer CFI compliant.
• CFI: Common Flash Interface and is an industry standard for ensuring compatibility among flash chips.
• CFI standards were introduced that enable the flash vendors to allow the configuration data to be read
from the flash devices. So system software could interrogate the flash devices and reconfigure itself.
• MTD supports the CFI command sets from Intel and AMD.

Flash Chips
NOR versus NAND Flash
Feature NAND Flash NOR Flash
Cell Structure Grid-like structure, series-connected Parallel cell structure
Read/Write Operations Optimized for sequential operations
Supports both random and sequential
operations
Access Speed
Slower random access, faster sequential
access
Faster random access, slower
sequential access
Endurance/Lifespan
Higher endurance, suitable for high-write-
cycle applications
Lower endurance compared to NAND,
suitable for lower-write-cycle
applications
Cost Generally more cost-effective per bit Typically more expensive per bit
Common Applications SSDs, USB drives, memory cards Embedded systems, firmware storage

Flash Disk
• Flash disks, also known as solid-state disks (SSDs) or flash storage drives, are storage devices that use
flash memory technology to store data.
• They are designed to serve as a replacement for traditional mechanical hard disk drives (HDDs) in
computers and other electronic devices.
Flash disks come in two types:
1. ATA-based (Advanced Technology Attachment) or IDE (Integrated Drive Electronics)
2. Linear

Flash Disk
Feature ATA-based Flash Disks Linear Flash Disks
Interface ATA (IDE: Integrated Drive Electronics) or SATA
(Advanced Technology Attachment)
Direct addressing (linear)
Controller
Includes built-in controller for managing
data transfer and storage
Typically accessed directly by the host
system, may not have a dedicated controller
File System
Compatibility
Supports standard file systems like FAT32,
NTFS, ext4, etc.
May require specialized software or drivers
for access
Access Speed Typically faster due to dedicated controller
May have slower access speeds compared
to ATA-based flash disks
Applications
Commonly used as primary or secondary
storage in laptops, desktops, servers, etc.
Used in embedded systems, industrial
applications, and legacy systems
Programming
No specialized programming required,
compatible with standard operating
systems
May require specialized software or drivers
for programming and access
Data Integrity
Includes features like wear-leveling, error
correction, and bad block management
May lack features like wear-leveling and error
correction, data integrity may be more
dependent on implementation and usage
patterns

MTD Architecture
The MTD architecture is divided into the following components.
1. MTD core: The MTD core module provides basic
functionality for managing flash memory devices.
This includes device registration, handling of MTD
partitions, and basic operations such as reading
and writing to flash memory. It implements the
character and block device mode
2. Low-level flash drivers: Responsible for interfacing
with the hardware of flash memory chips /controllers.
such as sending commands, reading and writing data,
erasing blocks, and managing bad blocks.

3. BSP for flash:. BSP for flash typically refers to the set
of software components and drivers provided by the
board manufacturer or a third-party vendor to support the
flash memory on a specific embedded hardware platform.
4. MTD applications: This can be either kernel
submodules such as JFFS2 or NFTL (NAND Flash
Translation Layer), or user-space applications such as
upgrade manager
MTD Architecture

MTD Driver for NOR Flash
Details of a NOR flash driver for Linux
The file mtd.c contains the code for a simple NOR flash based on the following assumptions
1. The flash device has a single erase region so that all sectors have the same size.
(An erase region is defined as an area of a chip that contains the sectors of the same size.)
2. The flash chip is accessed using a 4-byte bus width.
3. There are no locking, unlocking, suspend, and resume functionalities.

1. Module Initialization:
The code starts with including necessary headers.
It defines a macro FLASH_SIZE_BYTES to represent the size of the flash memory.
2. Structures:
struct my_nor_flash is defined to hold information about the NOR flash device.
3. Probe Function (my_nor_flash_probe):
• This function is called when the driver is being probed.
• It retrieves platform resources.
• Registers the MTD device using devm_mtd_device_register.
• Sets various properties of the MTD device such as size, type, flags, erase block size, etc.
• Initializes my_flash.mtd with the registered MTD device.

4. Device Tree Matching:
The driver uses Device Tree (of_device_id) to match with compatible strings specified in the device tree.
5. Platform Driver Initialization:
It initialises the platform driver structure with the probe function and other driver-related information.
6. Module Metadata:
Metadata such as license, author, and description is provided.
7. Error Handling:
Basic error handling is provided for resource retrieval and MTD device registration.
8. Cleanup:
Depending on the requirements, you might need to implement a cleanup routine to release resources when
the driver is unloaded.

Flash Mapping Driver
The process of flash-mapping driver
1. Creating and populating the mtd_info structure
2. Registering mtd_info with the MTD core

1. Filling up mtd_info for NOR Flash Chip
2. Filling up mtd_info for NAND Flash Chip
3. Registering mtd_info

• The low-level NOR hardware is dependent on the board.
• In case flash is connected directly to the processor hardware bus.
• The address to which the flash is memory mapped
• The size of the flash
• The bus width; this can be an 8-, 16-, or 32-bit bus
• Routines to do 8-,16-, and 32-bit read and write
• Routines to do a bulk copy

• The NOR flash map is defined in the map_info data structure.
• Database for the various board configurations is found in the drivers/mtd/maps directory.
• Once the map_info structure is filled, then the function do_map_probe() is invoked with the map_info as
an argument.
• This function returns a pointer to the mtd_info structure filled with the function pointers for operating on
the flash chip.

The following are the important pins found on a NAND flash chip.
• CE (Chip Enable) pin: When this pin is asserted low the NAND flash chip is selected.
• WE (Write Enable) pin: When this pin is asserted low, the NAND flash chip accepts data from the processor.
• RE (Read Enable) pin: When this pin is asserted low, the NAND flash chip sends out data to the processor.
• CLE (Command Latch Enable) pin and ALE (Address Latch Enable) pin.
• WP (Write Protect) pin: This pin can be used for write protection.
• RB (Ready Busy) pin: This is used in data-transfer phases to indicate that the chip is in use.
• IO pins: These are used for data transfer.
• These pins determine the destination of the operations on the NAND chip.

• A NAND-based mapping driver needs to allocate the mtd_info structure.
• The structure nand_chip is filled by the NAND mapping driver.
The following steps are done by the NAND mapping driver.
• Allocate the mtd_info structure.
• Allocate a nand_chip structure and fill up the required fields.
• Make the mtd_info’s priv field point to the nand_chip structure.
• Call the function nand_scan(), which will probe for the NAND chip and fill the mtd_info structure with the
functions for NAND operation.
• Register the mtd_info structure with the MTD core.

3. Registering mtd_info
• The basis of the registration is the function add_mtd_device() function, which adds the device to the
mtd_table[] array.
• In most cases, you would not use this function directly because you want to create partitions on the chip.

BSP.pptx

Recommended

Recommended

More Related Content

Similar to BSP.pptx

Similar to BSP.pptx (20)

More from taruian

More from taruian (20)

Recently uploaded

Recently uploaded (20)

BSP.pptx