RTFS sataSample problem with NDK 2.0.0 at OMAPL138

Hi Frank,

Can you try to break this problem up into two different scenarios, one for NDK, one for RTFS?  This will make it easier to debug.

jun huang2 said:

The program stoped here. And I found that the function ATA_SubmitIdentify stop the program moving.

First, can you try just the SATA example (sataSample) WITHOUT the NDK added, and try your same cache experiment? Do you see the same failure?

jun huang2 said:

When I comment rtfs code, use L2cache, the network speed can up to more than 2Mbps. It satisfy the requirements

When I don't use L2cache, use rtfs and it work well, but the network speed less than 100kbps.

The NDK transfer speeds are likely being affected by the cache being turned off.  Can you try to make this same experiment with ONLY the NDK helloworld example?  (No RTFS code added).

I'm guessing that you will see the same speed degradation when you turn the cache off for the helloWorld example.

Steve

Hi Steve

First,   I have test the RTFS demo sataSample (rtfs_1_10_02_32\packages\ti\rtfs\examples\sata\bios5\evm6748) in debug mode, WITHOUT the NDK.  When I use L2cache 256K, it has the same failure, stopping at the function ATA_SubmitIdentify. So I think may be the RTFS has conficts with L2cache.

Second, I need some time to make the experiment with helloWorld. I will reply later.

Frank

Frank,

jun huang2 said:

1.First problem is when I set L2cache 256K, it work wrong.
I add this config to my tcf:
bios.GBL.C64PLUSL2CFG = "256k";
bios.GBL.C64PLUSMAR160to191 = 0x00000001;
bios.GBL.C64PLUSMAR192to223 = 0x00000001;
bios.GBL.C64PLUSMAR224to255 = 0x00000001;
bios.MEM.instance("IRAM").destroy();

I just wanted to make sure that you are aware of how the above cache settings work.  For example,

bios.GBL.C64PLUSMAR160to191 = 0x00000001;

Setting this range to 0x1 only enables bit 160 of the MAR.  This corresponds to the memory range A000 0000h - A0FF FFFFh (see sprufk5a.pdf for details on the MAR ranges).

The right hand value in that statement is a bit mask.  If you want to enable the full range, meaning all bits 160 - 191, you should set that mask to be 0xFFFF FFFF.

This would result in the entire range A000 0000h - BFFF FFFFh being made cacheable.

Lastly, just to double check, please make sure you also have this line in your *.tcf file:

bios.GBL.C64PLUSCONFIGURE = 1;

Steve

Steve;

1.  I have checked that my *.tcf including the setting

     bios.GBL.C64PLUSCONFIGURE = 1;

2. I copyed the L2cache settings from other demo project.

    In my project, the DDR starts at 0xC0000000, and 0x4bd825 are used. 

   I set  bios.GBL.C64PLUSMAR192to223 = 0x00000001, which makes C000 0000h - C0FF FFFFh

being cacheable. So I think the  cache settings  have no problem.

Then I have done more experiments with different cache settings, such as:

 1)  bios.GBL.C64PLUSCONFIGURE = 1;

bios.GBL.C64PLUSL2CFG = "256k";

bios.GBL.C64PLUSMAR128to159 = 0x00000001;
bios.GBL.C64PLUSMAR192to223 = 0xffffffff;

2)  bios.GBL.C64PLUSCONFIGURE = 1;

bios.GBL.C64PLUSL2CFG = "256k";

bios.GBL.C64PLUSMAR192to223 = 0xffffffff;

But the problem still exists. The driver initial failure.

3 . I test my program with ONLY the NDK, removed the rtfs,and the cache being turned off.

The NDK transfer speeds are about 100kbps, 

In my project, the  NDK transfer triggered by the EDMA interrupt

So I need to resolve the conflict problem between the rtfs and L2cache

jun huang2,

Can you try the SATA example with the following scenarios?  And reply with the results?

A. enable the cache, but disable all MARs

bios.GBL.C64PLUSCONFIGURE = 1;

bios.GBL.C64PLUSL2CFG = "256k";

bios.GBL.C64PLUSMAR128to159 = 0x0;
bios.GBL.C64PLUSMAR192to223 = 0x0;

B. Enable the cache, and only enable the L3 MAR:

bios.GBL.C64PLUSCONFIGURE = 1;

bios.GBL.C64PLUSL2CFG = "256k";

bios.GBL.C64PLUSMAR128to159 = 0x00000001;

bios.GBL.C64PLUSMAR192to223 = 0x0;

C. Enable the cache, and only enable the L2 MAR:

bios.GBL.C64PLUSCONFIGURE = 1;

bios.GBL.C64PLUSL2CFG = "256k";

bios.GBL.C64PLUSMAR128to159 = 0x0;

bios.GBL.C64PLUSMAR192to223 = 0xffffffff;

Steve

Hi Steve:

I test the SATA example with 3 different scenarios. The problem still exists.

The A and B scenarios have the same results. They stopped at two different position.

Some time they stopped at 

Other time they stopped at 

The  C scenario has different result

Hi Steve:

        I have tested 3 scenarios.

        Please give me more suggestion.

Hi Frank,

I've been trying to track this problem down.  I see that there was a bug that was reported as fixed that looks to be related to the issue you are seeing:

SDOCM00060381 usbhostmsc example and sata example fail when cache is enabled for DDR on Freon.

The bug states that this issue was fixed in the BIOSUSB product.  But, I don't think you are using BIOSUSB, and furthermore I believe you are using the latest PSP drivers version 1.30.01.

I'll keep digging and get back to you.

Steve

Frank,

Coming back to the 3 scenarios you tried.  I was hoping that at least one of those would work, to give us a better clue as to what the problem is.  But since all 3 scenarios still failed, it didn't help us much, other than letting us know that it just doesn't work with the cache turned on.

Which components are you using in your application?  I think you have BIOS, NDK, RTFS, PSP drivers and EDMA.  Is that correct?  Or are you using any other software component?

jun huang2 said:

When I comment rtfs code, use L2cache, the network speed can up to more than 2Mbps. It satisfy the requirements

When I don't use L2cache, use rtfs and it work well, but the network speed less than 100kbps.

Can you check to see where the NDK is being placed in this scenario?  Since the app does not crash with these settings, I wonder if we can find a way to increase your network speeds for this case.

Where are the NDK code and data sections being placed in this scenario?  Also, what are the interrupt priorities for the NDK stack thread (probably a Task called "StackTest" in your version of the NDK)?  What are the priorities being used for RTFS?

The idea I have is to move as much of the NDK data sections into internal memory as possible, but leave the RTFS or SATA stuff out in external memory/DDR.

I'm hoping that having the NDK packet buffers in faster, internal memory will help with the slow speeds you are seeing in this scenario.

---

One another note, if we want to take this further, in order to try to figure out which component is behaving badly (i.e. causing the crash), one idea is to move different components to/from internal/external memory.

For example, you would first start with *everything* in external memory and with the cache enabled, and verify if that works.

If it does, then try to move each component, one at a time, from external memory and then into internal memory.  Rebuild and test if it works with the given component in internal memory.

E.g., first try moving EDMA into internal RAM, while leaving NDK, PSP, BIOS, RTFS out in external memory.  Build and test.  Does the failure happen?  If so, then this would mean that EDMA could be the culprit.

Next, try moving EDMA back to external memory, then moving PSP into internal memory.  Does it fail?
 Then try RTFS, and so on.

-------------

Lastly, which platform file are you using (in your BIOS configuration *.tcf file)?
  Are you using the omapL138 platform?  If so, this platform preserves some memory for the ARM9.  But since you are on BIOS 5.x, you are only using the DSP processor, correct?

If so, then you should try the evm6748 platform as it will give you a lot more external memory, just in case you need that.

Steve