Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Why are you running "mw.b 0xc2000000 0xFF 0x400000" as part of your load? You are going to overwrite that RAM you just initialized when you do the following nand read.e?

I would see how fast the unit boots without running the fill. If you have to do a fill (and I don't understand why), then maybe used mw.l instead?

-Mike

Thanks Mike,
you are right i don't have to overwrite RAM contents so I modified the u-boot commands to be as the following:

U-Boot > setenv progfpga "sf probe 0; sf read 0xC0700000 0x580000 0x40000; loadfpga 0xC0700000"
U-Boot > setenv progarm "nand read.e 0xC2000000 0x0 0x400000 ; bootelf 0xC2000000"
U-Boot > setenv bootcmd "run progfpga;run progarm"
U-Boot > saveenv

But still having the same problem, CPU takes long time to read data from NAND Flash?could you tell me what is the typical time to boot from NAND flash? and how to minimize the reading time?

Note:
When I stopped the autoboot from running the "bootcmd", i have tried to run the two U-boot commands (first "run progfpga" and followed by "run progarm"), the CPU also takes along time to read the image from NAND Flash.

When I stopped the autoboot from running the "bootcmd", i have tried to run only the "progarm" command (without running the "progfpga" command),the CPU takes no time to read the image from NAND Flash and the application has been started immediately.

Hi Ahmed,

Sounds like the loaded FPGA is causing NAND read issues? Have you checked your FPGA image and made sure that in the bitstream generation options you are setting all unused I/O pins to "float"? By default they are pulled down. There are pins on the FPGA that are connected to the EMIFA bus, which might be causing contention and lots of retries. That may be the source of your problem.

-Mike

Hi Mike,
I had made what you said (sets all unused I/O pins to float), but I still have the same problem.
I have tried the "IndustrialIO.bin" FPGA image (instead of my image) and everything works fine (FPGA loaded with "IndustrialIO" and the CPU application has been started immediately).

Are there any other options should I set while generating the bit file?

If the FPGA is loading properly and you are floating the unused pins, then the bitstream generation settings are probably OK.

Are you using the EMIFA framework we provide in the BSP or your own? You might drop a chipscope in and watch the bus transactions from uBoot and see if there is something odd going on. E.g., is the WAIT pin being asserted for long periods of time or something like that. You might also double check your pin assignments are correct and all pins are RLOC'd in your constraints file. If you miss an assignment and it is getting assigned to an EMIFA pin that could cause trouble as well.

Beyond that, I don't have any suggestions. But it would seem that there is something with the FPGA that is messing with one of the EMIFA lines.

-Mike

And of course, one workaround might be to load the ARM application into memory from NAND first, then configure the FPGA, then launch the ARM app.

The only thing is that is there is contention on the EMIFA bus you should figure out where it is and fix it....

-Mike

You are right one of the EMIFA pins was used as a FPGA IO, after replacing this pin everything works as expected.
Thanks Mike.