When I access two GPMC devices, I got this error Unhandled fault: external abort on non-linefetch (0x1018) at 0x400210c0

I think they are on the beaglebone GPMC using two different chip selects..

Hi, Biser:

I am using AM335x family. You are right there is only one GPMC interface. I config the chip select 0 bank connected to Nand flash device, chip select 1 connected to FPGA using asynchronous non-multiplex mode interface,

My program is runing on the background to periodically access FPGA memory. it works fine.

Then I do cp file to NAND flash (which is configured as UBI file system), then I have the error and my background program is crashed.

Can somebody answer my question?

Thank you!

Is the mmap uncacheable and bufferable for both locations?

I'm just guessing, based on posts like this. Haven't actually done this myself.

http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/t/179925.aspx

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0246a/Cjajeggg.html

I'm just using a single chip select now, but I'm interested in using two for devices with different speeds.

Thank you very much for your suggestion, but I don't know how to force the memory to be uncacheble.

What I did to map the GPMC address like this:

if (mem_fd < 0)
 mem_fd = open("/dev/mem", O_RDWR | O_SYNC);
    if (mem_fd < 0) {
 perror("map(open)");
 return NULL;
    }

    ptr = mmap(NULL,length,PROT_READ|PROT_WRITE,MAP_SHARED,mem_fd,phys);

What should I do in order to map to uncached location?

Thank you!

Jin

Your code looks to be the same as mine. I believe that O_SYNC makes it uncacheable..

I think the bufferable means that if two masters try to "simultaneously" access the GPMC, one of them will be buffered (delayed) while the other completes.. I just see it being discussed in other posts that seem to be related, but I don't know if it is relevant here... (not sure how it could happen..) and I haven't found any posts on how to change it. I think it has to do with the memory management unit page tables.

My original thought was that something in your hardware was causing GPMC pins to be left in some state that was okay for one chip select, but not for the other.

Thank you very much for the hint.

Do you have any suggection how can I prove the GPMC is broken in such way, access one is ok, not the second? I did restart the task, and just access the one which was broken. It seems fine until I start the first task, then it will die. It seems the GPMC is in some kind state for temperary. Do you have any advice how to verify the problem?

Jin 

Hey, isn't *my* post the verified answer? I want my points! ;-)

Hi, Drew:

You got full points if this makes you feel better. Anyway I got the result! :)

Sincerely thank you for giving ideas where to look along the way to debug!

Do you know where TI have the document to state there is a period time the system should not access the GPMC chip select range if tineout occurs.

Have a nice day!

Jin

Thanks, I know -- I just threw out suggestions and happened to stumble across the register you needed to change.. but I feel I helped a little. (Yay I now have one answer for somebody else!)

It seemed to me that something was timing out to cause the abort... so I googled "gpmc timeout" and came across the following post..

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/29248.aspx

So, I guess if you read all 4500 pages of the TRM it is implied right there in the register descriptions. :-)

Hi, There:

What do you mean you helped a little, You helped a lot!  You are the best. Sometime I like to help people, but I am too busy on my own project. Maybe it is just an excuse. This is a fair new chip there are a lot of thing not stated well. I learned it hard way all along. I still have issues to fix.

I just don't know how the TI e2e works, next time you do the verify answer. :)

Jin

This message is for TI people:

I talked to somebody in TI a while ago. I bring this subject up again.

Regarding the GPMC timeout, we need to have an interrupt to tie to it. otherwise it is useless to set GPMC timeout, then keep pulling the GPMC register somehow to figure it out if the system is GPMC timeout on certain chip select. Now I have to ditch the GPMC timeout, and use external device to do the job.

Jin