2008-08-23 13:47:08 Can BF527 support 640x480 LCD and larger under ucLinux?

aaa aaa (CHINA)

Message: 60946

I think someone here should analyised this question already, at least theoratically, since it is sort of an major indicator of the chip.

We have built 527 board connecting to 640x480 LCD (60Hz refresh rate, typical rate of cyrstal is 25MHz). With default SCLK=96MHz, the hardware is verified under VDSP and the display goes all fine.

However, after make ucLinux and fb driver running on the board, images on display flickers. We checked the status and found PPI reporting error when doing DMA, indicates there is underrun or overrun on PPI interface. it looks like that there is not enough bandwith on system bus so we tried to increase SCLK and flickers did not go even we set SCLK to 133MHz. The display only becomes OK until we manually set SCLK to 150MHz, which means we just overdrive the system bus.

527 only get a 16-bit bus, and we believe that will be a major bottle neck for big size display and video application. However, we dont really think ucLinux should occupy that much bandwith when it is idle, considering the display goes fine under VDSP env. at SCLK=96MHz

Lower the refresh rate of the LCD could also make the image stable, but lower the image quality also.

I dont really want to run an over-driven system. I guess there are some mis-config to ucLinux thus makes conflicts on system bus happen. Anyone here have similar experience that could give us some hints?

Thanks in advance.

I found similar problem on this link:

http://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?action=ForumBrowse&forum_id=39&_forum_thread_total_items=50&_forum_thread_page=2&_forum_action=ForumMessageBrowse&thread_id=28813

However, DDR interface on 548 has much better system bus performance than 527, so he might not see this problem.

QuoteReplyEditDelete

2008-08-24 21:10:50 Re: Can BF527 support 640x480 LCD and larger under ucLinux?

Robin Getz (UNITED STATES)

Message: 60951

aaa:

Have a look at:

https://docs.blackfin.uclinux.org/doku.php?id=ppi#troubleshooting

-Robin

QuoteReplyEditDelete

2008-08-25 11:32:52 Re: Can BF527 support 640x480 LCD and larger under ucLinux?

aaa aaa (CHINA)

Message: 61028

Thanks robin.

We have tried all methods on that link, and the only one works is the last item: reduce PPI clk. But as mentioned above, it also degrades image qualities, as the darker part of an image flicker somehow.

It is a bad news to us, as it looks like it touched up-limits of BF527 under ucLinux. If it is true then BF527 could not support LCD larger then 640x480, or maybe worse if we run some video applications, which will consume more bandwidth.

I just would like to clarify 2 questions:

1) Is there anyone actually analised this problem before, that what is the maximum resolution 52x could support under ucLinux?

2) How ucLinux will affect the system bus on 52x?

QuoteReplyEditDelete

2008-08-25 14:25:53 Re: Can BF527 support 640x480 LCD and larger under ucLinux?

Robin Getz (UNITED STATES)

Message: 61038

aaa:

This really has nothing to do with Linux or gcc - but the system level architecture - where everything runs from cache. (most bfin-elf-gcc and VDSP++ applications fit directly in L1 - Linux does not - that doesn't mean it is a Linux problem, but a system level bandwidth/cache issues).

But to answer your question - no, I don't think many people have done any calcultions, since it is too application specific.

-Robin

QuoteReplyEditDelete

2008-09-07 10:27:58 Re: Can BF527 support 640x480 LCD and larger under ucLinux?

aaa aaa (CHINA)

Message: 61757

Robin:

Thx but I could not agree you all. Though L1 cache does improve performance, but I don’t think it matter much in this case.

In our case, in order to support a 640x480 LCD, we allocated a 640x480x16bits buffer in SDRAM. The test program does exactly the same thing either under VDSP, or Linux: to move the data from this buffer in SDRAM, to PPI interface using DMA. In my understanding it will not make any difference in video data flow, either you compile the program under VDSP, or using GCC under Linux. The test program does nothing else but just initiating the DMA in both environments, i.e., no other instructions are executed after initiated the DMA. Then the only reason that makes the difference to cause LCD flicker is because the ucLinux impact the system bus somehow.

QuoteReplyEditDelete

2008-09-07 15:14:18 Re: Can BF527 support 640x480 LCD and larger under ucLinux?

Mike Frysinger (UNITED STATES)

Message: 61760

you're ignoring the important parts of Robin's points. Linux does not fit into L1 while VDSP does. that means Linux runs out of external memory and thus provides significant bus contention.

QuoteReplyEditDelete

2008-09-08 21:23:28 Re: Can BF527 support 640x480 LCD and larger under ucLinux?

Robin Getz (UNITED STATES)

Message: 61802

aaa:

>I could not agree with you

Just because you don't agree doesn't mean I'm not correct. (which I am).

>the test program does exactly the same thing in either under VDSP and Linux

That is where you are mistaken (and I am correct). in VDSP your application - is likely a single threaded application which is sitting in L1 instruction SRAM. The only bus activity is the PPI DMA. 640x480 is no problem in this environment. In Linux - there are many threads being run, which are all sitting in external memory, so there is alot of EBIU activity (cache misses, cache flushes, etc). Since that causes alot of EBIU traffic - the page open/closes from that causes the DMA traffic problems - 640x480 is a problem.

>The test program does nothing else but just initiating the DMA in both environments

Then you turned off the linux scheduler? and linux timer? and linux memory manager? and the userspace shell? and userspace init? and userspace telnetd? and ..... - there are many other Linux threads/applications running on the system than just your small application.

>the only reason that makes the difference to cause LCD flicker is because the uClinux impact the system bus somehow.

No - this is not a Linux issue - like I said before - this is a cache/architecture issue. If you run your VDSP application with multiple threads in L3 (with icache and dcache on) you will see the same thing as what you are doing with Linux.

If you ask a knowledgable VDSP person - they will tell you the same thing.

QuoteReplyEditDelete

2008-09-15 11:59:30 Re: Can BF527 support 640x480 LCD and larger under ucLinux?

aaa aaa (CHINA)

Message: 62175

Robin:

Thanks.

I agree all your comments this time, since it looks we are actually talking the same thing, but with different way. Whatever, i think the key point of this phenomene is something else have conflicts with PPI DMA on system bus, either its other Linux processes, or other VDSP threads.

But the point is, in a pure VDSP application we usually can control everything - the application structure, the behaviour of each thread, and the order they access the bus... We could have many application specific designs to reduce or eliminate this flicker.

In Linux however, we will have limitations doing so. As you said, lot of system components running, and lot of key system funtions rely on them. You can not break the structure of the OS to optimize.

Anyway, we are trying to figure out how exactly those Linux components would impact. We try to have a minimal system, basically having all un-neccessary components turned off. If we only focus on the case of our small video test program for an example, when this minimal system is 99% idle, the question is, why an almost complete idle system, will steal that much bandwidth to result in the flicker on PPI interface? We could have an estimation that for a 640x480 LCD, the required bandwidth to do normal display is 640x480x2(bytes)x50(Hz)=30MB/s which is bascially 50% bandwidth of the actually available sytem bus. Then it turns out that LInux compents will take other 50% under almost complete idle status? Even there still scheduler, timer, memory mgr. init running, this figure still looks somewhat too high.

So we try to find some suggestion here on why an idle Linux system consume so much bandwidth, which would be the most critical part that could be optimized?

Thanks again.

/aaa

QuoteReplyEditDelete

2008-09-15 12:55:03 Re: Can BF527 support 640x480 LCD and larger under ucLinux?

Robin Getz (UNITED STATES)

Message: 62177

aaa:

>why an almost complete idle system, will steal that much bandwidth to result in the flicker on PPI interface?

Like I said - cache.

everytime you get a cache miss - it is likely that you also have a page open/close - this contributes to many (30+) EBIU cycles of managment necessary to close the existing page, open the next.

Depending on how often this happens - the overhead can be alot, even for a realativity IDLE system.

QuoteReplyEditDelete

2008-09-15 23:55:22 Re: Can BF527 support 640x480 LCD and larger under ucLinux?

Sonic Zhang (CHINA)

Message: 62200

In addition, the register save/resore operations in context switch cost a lot of overhead in linux other than that in VDSP. Linux has to save/restore almost all registers and may cost 5000 cycles and more data cache missing on EBIU bus.

QuoteReplyEditDelete

2008-09-17 11:42:04 Re: Can BF527 support 640x480 LCD and larger under ucLinux?

aaa aaa (CHINA)

Message: 62318

>Depending on how often this happens - the overhead can be alot, even for a realativity IDLE system.

Thats the key point, how often. What exactly is "relatively IDLE"?

Below is the output from "top" command:

======================================

PID USER STATUS VSZ PPID %CPU %MEM COMMAND

125 root R 448 115 0.1 0.7 top

115 root S 544 1 0.0 0.8 sh

32 root SW< 0 2 0.0 0.0 khubd

51 root SW 0 2 0.0 0.0 pdflush

52 root SW 0 2 0.0 0.0 pdflush

54 root SW< 0 2 0.0 0.0 aio/0

87 root SW< 0 2 0.0 0.0 mtdblockd

89 root SW< 0 2 0.0 0.0 bfin-spi.0

53 root SW< 0 2 0.0 0.0 kswapd0

2 root SW< 0 0 0.0 0.0 kthreadd

3 root SWN 0 2 0.0 0.0 ksoftirqd/0

4 root SW< 0 2 0.0 0.0 events/0

5 root SW< 0 2 0.0 0.0 khelper

28 root SW< 0 2 0.0 0.0 kblockd/0

========================================

The system is 99.9% idle before test program started(top itself takes 0.1%). After test program started, since all it does is allocate the buffer, initiate the DMA and then keep idle, i think all comflicts will come from ucLinux components.

When doing compiling, We also have kernel optimization options checked, like scheduler in L1, timer in L1, irq in L1,...

To my understanding, under this circumstance, only scheduler and timer will be running. other processes, including those kernel process (khubd/pdflush/...), are seldomly scheduled(every few seconds?).

Context switch is really costful but in this case it should not happen that often.

Considering all these, i think the activities on system bus should be quite limited. At least 20MB/s looks too high.

Do i missed something?

thanks.

/aaa

QuoteReplyEditDelete

2008-09-17 12:04:39 Re: Can BF527 support 640x480 LCD and larger under ucLinux?

Michael Hennerich (GERMANY)

Message: 62319

The PPI FIFO sitting between the DMA and the PPI is 16 word deep FIFO.

Assuming you consume words at a rate of 20MHz (PPI_CLK = 20MHz),

Stalling or closing out the DMA to fetch new data for longer than 800ns will cause the PPI underrun to happen.