I'm porting recent Linux kernel to older existing hardware like the i.MX28 EVK kit from Freescale, and Karo TX28 board. I want to use a part of the NAND FLASH in the file system ("userfs partition" in the NAND).

First step is using ubiattach /dev/ubi_ctrl -m 6. This operation attempts to find a volume table, and reads the NAND chip, a number of gpmi_read_page operations. This leads to a DMA timout in start_dma_without_bch_irq (gpmi-nand.c). The weird thing is, the first number of read_page operations succeed. Then a time-out hits.

First impression was a timing issue. Changing the NAND timing did not change the observed behavior. Lots of debugging, mainly focused on the values in the registers of the GPMI, GPIO and interrupt collector did not reveal anything.

I managed to get some measurement connections on the control lines of the NAND chip in the i.MX28 EVK board. Using a Saleae (imitation) logic analyzer I can see a number of correct transactions (in the range of 20, 40, something). Then a read is set up, the NAND signals ready correct, the GPMI is asked to read data and the GPMI does clock the data out of the NAND, but fails to set the chip enable line (low active). Looks like the GPMI is no more working correct internally. Now the ISR for signaling the end of the read operation is not entered (I used the second chip enable line to signal that, debug output tells same story). Hence the timeout. Looks like the GPMI is "confused" internally.

I did check that the pin multiplexer for the chip enable line is still correct after the timeout. Judging on debug output the same happen on the Karo TX 28 (no measurement on the pins, I was not able to connect).

I have seen old mailings related to issues with i.MX23 and resetting the GPMI twice (U-boot and Linux kernel), causing the GPMI to hang up. PLaying around with that fix did not change. The issue is observed on Linux kernel 5.0.8 and 4.20.7. As far as I can judge, the NAND works correct when used from U-Boot. I tried the same timing setting as U-Boot uses, no luck.

Note also that on the Karo board a Samsung NAND is used, on the i.MX28 EVK a part from Spansion. So it seems not related to the particular NAND chip. Also note that the same is observed when the NAND partition is attached from the Linux boot command line in U-boot.

Question is what to do to find root cause, and possible fix.


First I have been doing lots of debugging, no solution found. Then I realized that I have on old Linux version which is working (it was prepared by another company, years ago). That proofs that it is not a hardware issue. Also the fact that 2 different hardware boards show the same issue indicate not a hardware issue. At some point I decided to try an old Linux version, as close as possible to the old working solution. That showed that kernel 3.16.68 was working OK, using an own build. My builds of 5.1.5 and 4.20.7 show the NAND FLASH issue. More experiments revealed that the last working kernel is 4.16.18, from 4.17.1 and later the issue is present. It appears that in between the NAND FLASH support for the Freescale GPMI peripheral has been restructured. I assume that is done by freescale, to accomodate newer processoers / SOCs. It looks like the support for the old hardware is broken. I can not tell whether this is known at Freescale or not. There are signs that freescale is no more supporting the old i.MX28. Anyway, now it was time to analyze differences. The crucial difference appears to the a function call to adapt the clock frequency of the GPMI peripheral which was added. For whatever reason after commenting out this one single call the GPMI peripheral seems to work correct with the NAND FLASH. This code resides in file "drivers/mtd/nand/raw/gpminand/gpmi-lib.c", function "gpmi_nfc_apply_timings". Just comment out the call to "clk_set_rate". At least for me this works. Later I realized that it would be better to only avoid the call when the processor is i.MX28, to allow it to work for later chips.

I did not analyze what the clk_set_rate exactly does, and how it should be invoked to work for all processors. I do not have other hardware, so would not be able to check that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.