Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

Koen Beel
2011-08-01T15:14:07Z

[-- Attachment #1: Type: text/plain, Size: 4823 bytes --]

Hi,

Don't think it's a hardware issue. After all it is working on the
mx23evk using the Freescale BSP based on 2.6.35.3.
Now I tested using this kernel command line:
mtdparts=gpmi-nand:20m(boot),-(user) gpmi_debug_init
(So I removed the ubi rootfs stuff, see previous mails).

Its booting fine now without complaining about dma timeouts.

Have tried flash_eraseall /dev/mtd1. Now it's complaining and thinking
all blocks are bad. So a "flash_erase: Skipping bad block at 1db00000"
message for every erase block.
Writing 1 to /sys/devices/platform/imx23-gpmi-nand/ignorebad, makes to
go a little further giving 'only one' error but I doubt it's working
at all. See attached log file.

When the trying ubiformat /dev/mtd1 its stopping with a dma timeout.
Every subsequent action (e.g. using ubiformat or flash_eraseall) using
that dma channel is failing.
I have put a printk in mxs-dma.c around line 387:

if (mxs_chan->status == DMA_IN_PROGRESS && !append)
{
pr_err("dma already in progess!\n");
return NULL;
}

I see that printk also in the log file in attach. Seems like the
mxs-dma is failing at some point and for the rest of the time always
keeps it's status at DMA_IN_PROGRESS

Any input or feedback is welcome.

Regards,
Koen

On Sun, Jul 31, 2011 at 3:51 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> On Friday, July 29, 2011 05:00:48 PM Koen Beel wrote:
>> On Fri, Jul 29, 2011 at 2:41 PM, Lothar Waßmann <LW@karo-electronics.de>
> wrote:
>> > Hi,
>> >
>> > Koen Beel writes:
>> >> Hi,
>> >>
>> >> On Fri, Jul 29, 2011 at 9:20 AM, Lothar Waßmann <LW@karo-electronics.de>
> wrote:
>> >> > Hi,
>> >> >
>> >> > Koen Beel writes:
>> >> >> Hi,
>> >> >>
>> >> >> I have test on mx23evk board. Still see the same issues.
>> >> >>
>> >> >> On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie <b32955@freescale.com>
> wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > Thanks for your test.
>> >> >> >
>> >> >> >> Hi,
>> >> >> >>
>> >> >> >> It's not really working for me.
>> >> >> >> I've applied all gpmi-nand driver patches and the dma driver
>> >> >> >> patches.
>> >> >> >>
>> >> >> >> I have added following kernel parameters:
>> >> >> >> mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
>> >> >> >> rootfstype=ubifs gpmi_debug_init
>> >> >> >>
>> >> >> >> During boot I get already get DMA timeout:
>> >> >> >> [    2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout,
>> >> >> >> last DMA
>> >> >> >>
>> >> >> >> :1
>> >> >> >>
>> >> >> >> [    3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
>> >> >> >> ...
>> >> >> >> (see log file in attach line 89)
>> >> >>
>> >> >> I still see this DMA timeout when booting.
>> >> >> What kernel parameters do you use? I still use same as above.
>> >> >
>> >> > Do you have an SD card in the system? I'm getting the same error when
>> >> > accessing an SD card. Without SD card I can use the flash without any
>> >> > errors.
>> >>
>> >> No SD card in the system. At least not on my mx23evk board.
>> >> My real target hardware has a SDIO wifi chip.
>> >>
>> >> Are you also testing on the mx23evk board? Really strange it is not
>> >> reproducible here then.
>> >> Anyone using mx23evk please give:
>> >> - revision number of board (I have tested on rev C1)
>> >> - kernel parameter used (see previous mail for mine)
>> >
>> > It's getting ever more strange. I only have problems with concurrent
>> > access to the flash and SD-card when I do file system based accessed
>> > to the SD card.
>> > A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash
>> > works well, while mounting the SD card and doing an 'ls' produces
>> > immediate BCH DMA timeouts.
>> >
>> > Perhaps someone can make anything out of that.
>>
>> I have checked and the function dma_irq_callback is never called
>> during my tests. This means the DMA transfer does not even works once.
>>
>> Also no clue here ...
>
> Aren't you getting some undervolt on the powerrail for example ? btw the driver
> looks a bit crappy to me, but let's believe it works ;-)
>
>>
>> > Lothar Waßmann
>> > --
>> > ___________________________________________________________
>> >
>> > Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
>> > Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
>> > Geschäftsführer: Matthias Kaussen
>> > Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
>> >
>> > www.karo-electronics.de | info@karo-electronics.de
>> > ___________________________________________________________
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

[-- Attachment #2: log1 --]
[-- Type: application/octet-stream, Size: 2645 bytes --]

# flash_eraseall /dev/mtd1
flash_eraseall has been replaced by `flash_erase <mtddev> 0 0`; please use it
Erasing 512 Kibyte @ 5c80000 -- 2 % complete libmtd: error!: MEMERASE64 ioctl failed for eraseblock 185 (mtd1)
error 5 (Input/output error)
flash_erase: error!: /dev/mtd1: MTD Erase failure
error 5 (Input/output error)
Erasing 512 Kibyte @ feb80000 -- 100 % complete
# ubiformat /dev/mtd1
ubiformat: mtd1 (nand), size 4273995776 bytes (4.0 GiB), 8152 eraseblocks of 524288 bytes (512.0 KiB), min. I/O size 4096 bytes
libscan: scanning eraseblock 0 -- 0 % complete [ 222.730000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA :1
[ 223.730000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
[ 223.730000] [ mil_ecc_read_page : 1054 ] Error in ECC-based read: -110
libmtd: error!: cannot read 64 bytes from mtd1 (eraseblock 0, offset 0)
error 110 (Connection timed out)
ubiformat: error!: failed to scan mtd1 (/dev/mtd1)
#
#
# ubiformat /dev/mtd1
ubiformat: mtd1 (nand), [ 229.490000] dma already in progess!
size 4273995776 bytes (4.0 GiB),[ 229.500000] [ gpmi_send_command : 749 ] step 1 error
8152 eraseblocks of 524288 bytes (512.0 KiB), min. I/O size 4096 bytes
libscan: scanning eraseblock 0 -- 0 % complete [ 229.520000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1
[ 229.520000] dma already in progess!
[ 229.520000] [ gpmi_send_command : 749 ] step 1 error
[ 229.530000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1
[ 229.540000] dma already in progess!
[ 229.540000] [ gpmi_read_page : 924 ] step 1 error
[ 229.540000] [ mil_ecc_read_page : 1054 ] Error in ECC-based read: -1
libmtd: error!: cannot read 64 bytes from mtd1 (eraseblock 0, offset 0)
error 1 (Operation not permitted)
ubiformat: error!: failed to scan mtd1 (/dev/mtd1)
#
#
# ubiformat /dev/mtd1
ubiformat: mtd1 (nand), [ 237.360000] dma already in progess!
size 4273995776 bytes (4.0 GiB),[ 237.370000] [ gpmi_send_command : 749 ] step 1 error
8152 eraseblocks of 524288 bytes (512.0 KiB), min. I/O size 4096 bytes
libscan: scanning eraseblock 0 -- 0 % complete [ 237.390000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1
[ 237.390000] dma already in progess!
[ 237.400000] [ gpmi_send_command : 749 ] step 1 error
[ 237.400000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1
[ 237.410000] dma already in progess!
[ 237.410000] [ gpmi_read_page : 924 ] step 1 error
[ 237.420000] [ mil_ecc_read_page : 1054 ] Error in ECC-based read: -1
libmtd: error!: cannot read 64 bytes from mtd1 (eraseblock 0, offset 0)
error 1 (Operation not permitted)
ubiformat: error!: failed to scan mtd1 (/dev/mtd1)