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

Tue Aug 2 04:55:16 EDT 2011

Hi,

On Tue, Aug 2, 2011 at 9:44 AM, Huang Shijie <b32955 at freescale.com> wrote:
> Hi,
>>
>> Hi,
>>
>> On Tue, Aug 2, 2011 at 8:37 AM, Huang Shijie<b32955 at freescale.com>  wrote:
>>>
>>> Hi,
>>>>
>>>> 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.
>>>
>>> I doubt the Freescale BSP has fix the conflict, while the community
>>> kernel
>>> does not
>>> fix it.
>>> Anyway, I will do more test on the mx23 board myself.
>>
>> Strange indeed. I suspect that the BSP used another way to mark bad
>> blocks.
>>
>>>
>>>
>>>> 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.
>>>
>>> ok.
>>
>> That's mainly because the ubi stuff is not done at startup.
>>
>>>> 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
>>>
>>> This is a very dangerous interface.
>>
>> I know but it solved an issue here. Now flash_eraseall seems to be
>> working again without that ignorebad turned on (only finds one bad
>> erase blcok).
>
> Could you mail me your flash_eraseall?
> Mine  does not work.

You want my flash_eraseall binary?

I build all userspace, kernel, bootloader and toolchain using
buildroot ( http://buildroot.uclibc.org/download.html ), which also
includes all flash tools like flash_eraseall and ubiformat. In the
buildroot menuconfig check the packages under 'Package Selection for
the target > Hardware handling > mtd/jffs2 utilities'
Buildroot will build everything needed to get a working system,
including toolchain, uclibc, ... I really recommend that.

Right now I use a kernel with the full rootfs as initramfs (standard
option in buildroot). I just load the uImage (contains kernel and
initramfs) using tftp in uboot. This way I'm not dependent on
mmc/nfs/nand (no eth or mmc on my actual target and nand/ubi not yet
working). Only downside is that I use some memory for it and I don't
have any persistent storage on the rootfs right now.

I have adapted buildroot a little to build the kernel out of tree.

Anyway, if you want my flash_eraseall binary, see attachment.

Regards,
Koen

>
> so I can test your flash_eraseall first.
>
> Best Regards
> Huang Shijie
>>
>> Again: I suspect that the BSP used another way to mark bad blocks.
>>
>>>> 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.
>>>
>>> echo 0x20>  /sys/devices/platform/imx23-gpmi-nand/gpmi_debug
>>>
>>> to show the GPMI register when the DMA timeout occurs.
>>
>> Don't have this sysfs interface here. I also don't see where it is
>> registered in the driver code.
>> Anyway I have hardcoded GPMI_DEBUG_CRAZY in gpmi_debug_setup.
>>
>> log file attached.
>>
>> Regards,
>> Koen
>>
>>>
>>> Best Regards
>>> Huang Shijie
>>>>
>>>> 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 at 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 at karo-electronics.de>
>>>>>
>>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Koen Beel writes:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Fri, Jul 29, 2011 at 9:20 AM, Lothar
>>>>>>>> Waßmann<LW at 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 at 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 at karo-electronics.de
>>>>>>> ___________________________________________________________
>>>>>>
>>>>>> _______________________________________________
>>>>>> linux-arm-kernel mailing list
>>>>>> linux-arm-kernel at lists.infradead.org
>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flash_eraseall
Type: application/octet-stream
Size: 149 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110802/83a12a4e/attachment.obj>