S3C2440 Nor Flash Driver (Twenty-four)

1.Nor Flash Hardware Introduction:

From the schematic diagram, we can see that NOR FLASH has address lines and data lines. It is similar to our SDRAM interface and can read data directly, but it cannot write data directly to SDRAM and requires commands.

1.1 There are 27 address lines in our 2440 (LADDR0~26). Why 27?

Because 2440 has 7 banks of memory blocks, each bank = 128M = (2^27)B, so there are 27 data lines in total

1.2 Why is the address line A0 of Nor Flash connected to LADDR1 of 2440?

Because Nor Flash has 16 bits of data, each address stores 2B of data, while each address of our 2440 stores 1B of data.

for example:

When 2440 accesses address 0x00, it will read 2B of data at address 0 on Nor Flash, and then the memory controller of 2440 will find the lower 8-bit byte based on 0X00 and return it to the CPU.

When 2440 accesses address 0x01, since the LDRR0 line of 2440 is not connected, it still accesses the 2B data at address 0 of Nor Flash. Then the memory controller finds the high 8-bit byte based on 0x01 and returns it to the CPU.

1.3 The difference between nand and nor:

NOR flash is more expensive than NAND in terms of connection, has a small capacity, and is slow to erase and write data. Its advantages are simple and stable interface, no bit reversal or bad blocks, and is often used to store critical data, while NAND flash is often used to store large-capacity data.

In 2440, the hardware switch is used to set OM0 to Nand boot or Nor boot, as shown in the following figure:

The specific parameters of OM0 are as follows, where the OM1 pin of 2440 is grounded

For nand boot: OM0 is grounded, the first 4KB of nand flash will be automatically loaded into the SRAM buffer built into 2440, and can be directly read and written

For NOR boot: OM0 is connected to the power supply, and the memory accessed by 2440 is NOR flash, which can be read directly, but not written directly.

2. The nor flash command is as follows (reference: MX29LV800BBTC.pdf and MX29LV160DBTI-70G.pdf)

Among them, word is for 16-bit nand and byte is for 8-bit nand.

Since the flash model of our 2440 is MX29LV160DB, the device ID is 0x2249 and the manufacturer ID is C2H.

2.1 For example, when we want to read the ID operation:

NOR manual:

Write AAH to address 555H (send unlock address)

Write 55H to address 2AAH (send unlock address)

Write 90H to address 555H (send command)

Read address 0 to get the manufacturer ID: C2H

Read address 1 to get device ID: 2249

Exit the read ID state: write F0H to any address

(A1 of 2440 is connected to A0 of NOR, so 2440 sends (555H<<1, left shift 1 bit is equivalent to multiplication by 2), and NOR can receive the address 555H)

UBOOT operation:

Write AAH to address AAAH mw.w aaa aa 

Write 55H to address 554H mw.w 554 55 

Write 90H to address AAAH mw.w aaa 90 

Read address 0 to get the manufacturer ID: C2H md.w 0 1 (1: means read once)

Read address 1 to get device ID: 2249 md.w 2 1

Exit the read ID state: write F0H to any address mw.w 0 f0

2.2 There are two specifications for NOR FLASH, jedec and cfi (common flash interface)

each

Just like nand flash, the parameters of nor flash (name, capacity, bit width, etc.) are determined by reading the ID to match the jedec_table[] array in drivers/mtd/chips/jedec_probe.c in the kernel, as shown in the following figure

2.2.1 [0] = MTD_UADDR_0x0555_0x02AA

Indicates that the unlock address is 0x555, 0x2AAAM, where array [0] indicates that it belongs to 8-bit flash

2.2.2 cmdset

Which command to use, generally CmdSet=0xFFF0

2.2.3 .NumEraseRegions= 1

Only 1 different sector area

2.2.4 ERASEINFO(0x10000,64)

There are 64 sectors in total, each sector is 64KB (0x10000)

cfi

Just save these parameters in the specified address in cfi mode, and write 0x98 to the 0x55 address of nor to enter cfi mode (as can be seen from the CFI Query in the above figure)

Some commands in cfi mode are shown in the following figure:

When we are in cfi mode, for example, reading the data at address 0x27 of nor, we can read the capacity of nor.

NOR Manual:

Enter CFI mode: write 98H to 55H

Read data: read 10H to get 0051

Read data: read 11H to get 0052

Read data: read 12H to get 0059

Nor capacity: read 27H to get the capacity

Exit CFI mode: reset

(A1 of 2440 is connected to A0 of NOR, so 2440 sends (555H<<1, left shift 1 bit is equivalent to multiplication by 2), and NOR can receive the address 555H)

UBOOT operation:

Enter CFI mode: write 98H to AAH mw.w aa 98

Read data: read 20H to get 0051 md.w 20 1 (Q)

Read data: read 22H to get 0052 md.w 22 1 (R)

Read data: read 24H to get 0059 md.w 24 1 (Y)

nor capacity: read 4EH to get the capacity md.w 4e 1 (15)

Exit CFI mode: reset mw.w 0 f0

Read 0x15, the decimal value of 0x15 is 21, as shown below, which corresponds to the 21 NOR address lines in our schematic diagram, so the capacity is 2^21=2097152=2MB

2.3 Why is the A20 pin not connected in the above picture?

For 2440, the capacity of A0~A19 is exactly 2MB, which is consistent with the data read in cfi mode, so A20 is not connected.

2.4 Write data operation: (Program)

At address 0x100000 (1M), write 0x1234

The data obtained is still the original data, so it cannot be written like memory

At address 0x30000000 (memory), write 0x1234

The data obtained is 0x1234

NOR Manual:

Write AAH to address 555H

Write 55H to address 2AAH

Write A0H to address 555H

Write PD to address PA

(A1 of 2440 is connected to A0 of NOR, so 2440 sends (555H<<1, left shift 1 bit is equivalent to multiplication by 2), and NOR can receive the address 555H)

UBOOT operation:

Write AAH to address AAAH mw.w aaa aa

Write 55H to address 554H mw.w 554 55

Write A0H to address AAAH mw.w aaa a0

Write 1234h to address 0x100000 mw.w 100000 1234

Read data: read 0x100000 to get 1234 md.w 100000 1

3. Next, let's analyze how to write the NOR flash driver

3.1 Let's recall the previous nand flash driver:

The nand flash driver will be placed in the kernel's mtd device, and the mtd device knows how to operate the nand flash through commands/addresses/data, so our previous nand flash driver only implemented hardware-related operations (constructing mtd_info, nand_chip structures, starting the nand controller, etc.)

Similarly, the NOR flash driver is also placed in the kernel's MTD device. The MTD device also knows how to read, write, and erase NOR, but it does not know the bit width (number of data lines) and base address of NOR flash. Therefore, our NOR flash driver also needs to implement hardware-related operations and provide MTD device calls.

3.2 Refer to the kernel's built-in NOR driver: drivers/mtd/maps/physmap.c

Enter its init function:

It is found that two platform device drivers are registered and enter the physmap_flash structure:

Found 3 undefined variables:

CONFIG_MTD_PHYSMAP_BANKWIDTH: Byte width of the NOR flash

CONFIG_MTD_PHYSMAP_START: physical base address of NOR flash

CONFIG_MTD_PHYSMAP_LEN: nand flash capacity length

These three variables are configured through the linux menuconfig menu. If you fill in the values ​​yourself, you don't need to use the menuconfig menu configuration.

3.3 Next we will configure the kernel and then hang the nor flash driver that comes with this kernel to experiment

3.4 First make menuconfig, configure the above 3 variables, and then set it as a module

 -> Device Drivers                                                   

          -> Memory Technology Device (MTD) support (MTD [=y])             

          -> Mapping drivers for chip access //Enter the mapping driver

CFI Flash device in physical memory map //Nor flash that supports cfi is set as a module

  │ │ (0x0) Physical start address of flash mapping //Set the physical base address  

  │ │ (0X1000000) Physical length of flash mapping //Set the capacity length, which must be greater than or equal to 2MB of NOR (0x1000000=16MB)

  │ │ (2) Bank width in octets //Set the byte width. Since the NOR flash is 16 bits, it is equal to 2 (2 bytes * 8 bits = 16 bits)

3.5 make modules

As shown in the figure below, you can see that physmap.c is compiled into a .ko module

3.6 Then put it in the nfs directory and start the development board

cp drivers/mtd/maps/physmap.ko  /work/nfsroot/first_fs

nfs 30000000 192.168.1.3:/work/nfsroot/uImage_nonand

bootm 30000000

As shown in the figure below, you can see that two mtd0 character devices and one mtd0 block device are created:

4. Next, we will analyze physmap.c and see how to write the NOR flash driver.

The probe function of physmap.c is as follows:

struct physmap_flash_info {

       struct mtd_info *mtd; //Realize the read, write, erase and other operations on the flash

       struct map_info map; //Store hardware related structures

       struct resource             *res;

#ifdef CONFIG_MTD_PARTITIONS

       int                 nr_parts;

       struct mtd_partition      *parts;

#endif

};

static const char *rom_probe_types[] = { "cfi_probe", "jedec_probe", "map_rom", NULL };    //芯片名称

... ...

static int physmap_flash_probe(struct platform_device *dev)

{

       const char **probe_type;

       ... ...

       /*1. Allocate structure*/

       info = kzalloc(sizeof(struct physmap_flash_info), GFP_KERNEL);

       /*2. Set the map_info structure*/

　　　　info->map.name = dev->dev.bus_id; //norflash name

       info->map.phys = dev->resource->start; //Physical base address

       info->map.size = dev->resource->end - dev->resource->start + 1; //Capacity length

       info->map.bankwidth = physmap_data->width; //Byte width

       info->map.virt = ioremap(info->map.phys, info->map.size); //Virtual address

       simple_map_init(&info->map); //Simply initialize other members of map_info

       probe_type = rom_probe_types;

       /*3. Set the mtd_info structure*/

       /*Identify the chip by the name pointed to by probe_type. When do_map_probe() function returns NULL, it means it is not found*/

       /*When the corresponding chip mtd_info structure is found, it will be returned to the current info->mtd */

       for (; info->mtd == NULL && *probe_type != NULL; probe_type++)       

       info->mtd = do_map_probe(*probe_type, &info->map); //Identify the chip through do_map_probe ()