BSP.pptx

BOARD SUPPORT PACKAGES
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

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

2. ROS MODULE 3: BOARD SUPPORT PACKAGES (BSP)

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

4. 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,

5. 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)

6. 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

7. 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.

8. 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.

9. Introduction The BSP has two components; 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: Bootloader support Memory map support System timers Interrupt controller support Real-Time Clock (RTC) Serial support (debug and console) Bus support (PCI/ISA) DMA support Power management

10. 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: Kernel: This directory contains the CPU-specific routines for initializing, IRQ (interrupt request) set-up , interrupts , and traps routines . mm : Contains the hardware-specific TLB (translation lookaside buffer) set-up and exception-handling code .

11. Inserting BSP in Kernel Build Procedure 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.

12. Inserting BSP in Kernel Build Procedure 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 .

13. 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.

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

15. Boot loader Interface 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.

16. Boot loader Interface 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

17. Boot loader Interface 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

18. Boot loader Interface 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 .

19. Boot loader Interface Bootloader start-up sequence

20. Criteria in choosing a boot loader for a given embedded platform Boot loader Interface Support for the embedded hardware Licensing issues Storage footprint : Bootloaders support compression to save flash space. Support for network booting : Boot loaders support booting via the network. (protocols BOOTP, DHCP, and TFTP) Support for flash booting : Flash booting has two components, flash reader software and file system reader software Console UI : G ives 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 Upgrade solutions: requires a flash erase and flash writing software in the boot loader.

21. 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.

22. 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.

23. Memory Map There are three addresses that are seen on an embedded Linux system CPU untranslated or physical address : The address that is seen on the actual memory bus . 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.

24. 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 .

25. Memory Map Steps in the creation of the memory map for the system 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. 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

26. Interrupt Management Every board is unique with its hardware interrupt management , because of the PIC (Programmable Interrupt Controller) interface. Basic functionalities of a PIC 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.

27. Basic functionalities of a PIC 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 .

28. Basic functionalities of a PIC 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.

29. 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.

30. PCI Subsystem Peripheral Component Interconnect (PCI) 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.

31. PCI Subsystem Peripheral Component Interconnect (PCI) Memory Map Issues Configuration Space Access Interrupt Routing on the Board Uniqueness of PCI Architecture

32. PCI Subsystem Peripheral Component Interconnect (PCI) Uniqueness of PCI Architecture 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.

33. PCI Subsystem Peripheral Component Interconnect (PCI) Uniqueness of PCI Architecture 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.

34. PCI Subsystem Peripheral Component Interconnect (PCI) Uniqueness of PCI Architecture 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.

35. PCI Software Architecture The PCI software architecture can be divided into four layers for MIPS. 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

36. PCI Software Architecture The PCI software architecture can be divided into four layers for MIPS. 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.

37. PCI Software Architecture The PCI software architecture can be divided into four layers for MIPS. 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.

38. Timers There are two timers that need to be programmed by the BSP The Programmable Interval Timer (PIT): This timer is hooked to the timer interrupt that provides the system pulse or ticks. 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.

39. 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

40. 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 The system console for displaying all the boot messages Standard TTY ( teletypewriter) device 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.

41. 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.

42. 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. A processor Memory (both DRAM and flash memory) A network card A sound card An LCD-based display unit

43. Power Management The OS plays an important role in implementing the power management framework. 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 . Provides support for dynamically scaling the frequency and voltage depending on the system load Provides a driver framework, various device drivers can be written to exploit the power-saving modes of the peripherals Exports the power management framework to specific applications

44. Power Management OS needs to consider the following factors to use the sleep mode. 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. The time to come out of the sleep state should be fast so that real-time characteristics of the system are met The events that need to awaken the system must be evaluate d and incorporated into the software. 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.

45. Embedded Storage

46. 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

47. Flash Map On an embedded Linux system, a flash will be used for: Storing the boot loader Storing the OS image Storing the applications and application library images 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.

48. 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.

49. 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.

50. 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.

51. MTD—Memory Technology Device 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 10 3 (for MLC NAND) - 10 5 (NOR, SLC NAND) era

52. MTD—Memory Technology Device 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 device s. So system software could interrogate the flash devices and reconfigure itself . MTD supports the CFI command sets from Intel and AMD.

53. MTD—Memory Technology Device 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

54. MTD—Memory Technology Device 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: ATA-based (Advanced Technology Attachment) or IDE (Integrated Drive Electronics) Linear

55. MTD—Memory Technology Device 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

56. MTD Architecture The MTD architecture is divided into the following components. 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.

57. 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

58. 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 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.

59. MTD Driver for NOR Flash Details of a NOR flash driver for Linux 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.

60. MTD Driver for NOR Flash Details of a NOR flash driver for Linux 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.

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

62. Flash Mapping Driver Filling up mtd_info for NOR Flash Chip Filling up mtd_info for NAND Flash Chip Registering mtd_info

63. Flash Mapping Driver Filling up mtd_info for NOR Flash Chip The low-level NOR hardware is dependent on the board. I n 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

64. Flash Mapping Driver Filling up mtd_info for NOR Flash Chip 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.

65. 2. Filling up mtd_info for NAND Flash Chip Flash Mapping Driver 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.

66. 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. 2. Filling up mtd_info for NAND Flash Chip Flash Mapping Driver

67. 3. Registering mtd_info Flash Mapping Driver 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.

68. End of Module