Solve the nand read operation in Linux.

We have completed the nand read operation in Linux-general Linux technology-Linux programming and kernel information. The following is a detailed description. Finally, I used the real and virtual address conversion functions, read the written information correctly, and mounted the cramfs partition.

Finally, the read part of the nand driver was completed on the last night. Now we can start the file system from cramfs, and write should be faster. ECC checksum and yaffs still need time. Briefly record the experiences of debugging nand with LM brother over the past few days.

When I joined the Linux project team, LM brother started to read the relevant content of the nand driver, so he wrote the main program. I just developed it together to solve the problem. At the beginning, the serial port cannot output and 2.6 cannot start these historical issues. Remember to encounter the following problems:

(1) The DMA Operation must be performed on the real address. We didn't understand it at the beginning. Filling in the virtual address makes the simplest DMA program unable to run. Thanks to the reminder of brother Zhang, I suddenly realized that.

(2) After compiling the NAND driver, there is no mtd or mtdblock In the proc directory. We have fixed this silly problem all day, including re-registering the driver according to the method of Samsung 2410, the result shows that some MTD options are not selected when Make menuconfig is used.

(3) write the write command to check whether the nand controller is always 0 (busy ). It is common sense that when nand is finished, it should be idle. We read it but find that it is always busy. Finally, we found that the write_byte function in nand_base.c was not reloaded. As a result, when we assigned a value of 80 to the 32-bit register, the value was 80808080, while the nand controller startup command was 80000080, that is, when we write the command, we start the nand controller, which keeps the nand controller busy.

(4) in linux, MTD-layer read/write NAND is generally read from the OOB zone of 512B and 16B. Our nand controller is special and must read the content of 528B or the OOB of 16B at a time, write 528B at a time. As a result, when calling the write_buf (512) function, we also have to read 528B. When writing 512, we may have to read the OOB of 16B and write 528 again. The write is not complete yet.

(5) For DMA read/write, we have been using the method of opening up an area at the beginning of the memory, reading data from the dma to this, linux then use the real address + 0x90000000 virtual address to get. However, the reading is always incorrect. At the beginning, I thought the delay was not enough, and a long delay was added, which was much better, but there was still an error. So I kept reading the oob area of a region for testing, it is found that there is about 15% of the probability of reading into Bad blocks. The probability of reading errors is greater. Finally, we used dma_alloc_coherent () to solve the problem of ing between the virtual address and the actual address. Finally, we read all the correct information and can mount the cramfs file system.

In fact, a lot of trouble is caused by the fact that our nand controller must adopt DMA read/write. Other people's very simple read_buf functions have become very complicated ToT, the first contact with 4020 is very unfamiliar with this processor, resulting in a lot of problems, continue to work!