i.MX53 M4IF priory registers

[torus1000]

Hi

I have been checked about FIFO overrun/underrun of i.MX53 FEC.

I tried to compare the occurrence then change the priority field of FEC bus master(FBPM_M4_RD/FBPM_M4_WR) in the M4IF_F_BPR1 register as following command.

$ /unit_tests/memtool -32 63fd8044=00000044
$ /unit_tests/memtool -32 63fd8040 2

But it seems nothing changed. (Rate of FIFO overrun/underrun looks the same.)

What's wrong with my commands? Why this register update affect nothing?

BTW Is there any tools to monitor bus status like "/unit_tests/mmdc2" for the i.MX6?

Can anybody help me?

Thanks

[TomE · Accepted solution]

I see you are running Linux 2.6.35. Do you know what patch level it is? Where did you get it from, and what "release date" is it? The "latest" 2.6.35 is "imx_2.6.35_maintain":

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_2.6.35_maintain

Does your "drivers/net/fec.c" file at least have Fugang Duan's patches up to "ENGR00274895" on 2013-08-13"?

"ENGR00274895 net: fec: allow to allocate the enough DMA size for BD."

What are you doing to cause the FEC Traffic? What programs are you running? Are you running some test code or are you serving FTP or something? What is the data rate?

How are you monitoring the errors? Are you looking in "/sys/class/net/eth0/statistics/*"?

How have you got "CONFIG_FEC_NAPI" and "CONFIG_DMA_ZONE_SIZE" set in the Linux Config (.config file and Linux "make menuconfig")? Change them.

> memtool

> But it seems nothing changed.

Have you read back the register location to make sure your "memtool" command actually did something? On my build (probably different to yours) I use "devmem" to write to device memory locations.

You have listed some of the other things the device is doing, but have you tried to STOP any of them to see which one is interfering with the FEC? Are you reading or writing an SD card? Some of the drivers for that device can lock up the CPU for a very long time. Are you accessing NAND Flash? Are you accessing the Frame Buffer Device? Some drivers for that can lock up the whole system when they go to flush the cache.

Tom

[torus1000]

Dear Tom,

NXP staff kindly sent me several patches you mentioned. Unfortunately those were for Android OS so it will take time to apply and tune.

Anyway thanks a lot.

[b36401]

Possibly FEC is the only part of system that performes significant load so plaing with priority actually does not make sence to performance.

As for i.MX6 there is /unit_tests/mmdc2 for i.MX6 processor series as well.

Have a great day,
Victor

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[torus1000]

Dear Victor,

Thank you for your replying.

Possibly FEC is the only part of system that performes significant load so plaing with priority actually does not make sence to performance.

Like other systems, our system also have not only FEC but IPU VGA output which constantly access to the memory.
So I expected screen noise when bus was busy by heavy traffic of FEC after priority changed.
But I couldn't see any sign of data shortage for the screen.

Is there any way to confirm FEC bus priority set higher than IPU?

As for i.MX6 there is /unit_tests/mmdc2 for i.MX6 processor series as well.

How about i.MX53 processor series?
I checked imx-test package in ltib L2.6.35 for i.MX53QSB but I couldn't find mmdc2.c. Where can I get it?

* no mmdc2 building for i.MX53
https://patchwork.openembedded.org/patch/87323/

Best Regards.