Friday, June 26, 2009

Another suspect: DMA starvation (updated: not really)

I've been thinking about the slowness problem and did some tests. I have another suspect: DMA starvation.

I think that as I already mentioned in the previous post, the original firmware doesn't reconfigure the LCD stuff if it is already configured, which means that the LCD stays configured as I do in the dual bool SPL code.

And in the SPL code, I set the pixel clock to 16MHz. It is quite high and has the advantage of a high refresh rate which is why some display artifacts in the emulators seem to be gone.

The downside is that it consumes a large amount of DMA bandwidth and the rest of functions that need DMA, like NAND flash / miniSD access, get starved.

I've verified that in linux when I set the LCD pixel clock to 24MHz the LCD works fine buy the kernel can't read from the miniSD. I suppose something similar is happening in the original firmware. The guy that ported linux to the onda vx747 also mentioned this problem (DMA starvation) and he implemented DMA round robin priority, but I'm not sure if that's the way to go because I'm sure we don't want the LCD display to be affected by disk access (either NAND of miniSD). He also implemented some optimizations in the framebuffer driver that I still have lo give a look at.

I have two ways of fixing the problem:
  1. Deinitialize the LCD just before jumping to the original firmware system loader. I don't know how to do this in an effective way because I don't know exactly how the original firmware detects that the LCD has already been initialized.
  2. Find out the LCD pixel clock that the original firmware is using and use it in the SPL. This is done by programming an application to run on the original firmware that reads the configuration registers and saves them to a log file.
I'll give a try to both approaches.

UPDATE: I've read all the internal registers both with and without dual boot. As suspected, the LCD pixel clock is different... but it is actually lower with dual boot !!!. That trashes my DMA starvation theory. There are some other differences (in particular some GPIO registers) that I'm investigating. Stay tuned.

Dual boot pixclk = 8 MHz
Original FW pixclk = 16.8 MHz
Posted by at 12:44 PM

5 comments:

  1. booboo ... thanks for the release and quick reponse

    Is there also not a third option (as elluded to by your previous post) and thats just to remove the splashscreen for now..

    If you need help testing let me know.

    Regards
    ReplyDelete
  2. Hum, It would be good to test if for example 12MHz would give a snappier menu but still remove (most of) the screen tearing in emulators, seen the most emulators only read prestty small files I assume the DMA "starvation" will only play big when parsing big files like video (aldo in my tests with current dual boot any video re-encoded/scaled back to 320x240 for the dingoo plays very fine) or so...
    I know the emulator screen tearing is not something you're working on, but if this can be fixed without impacting to much other stuff i would be *very* happy.
    If you want me to run something to get those registers, let me know.
    ReplyDelete
  3. And an afterthought, maybe the original FW simply does not set a pixel clock and uses the default when the hardware is initialized? no idea if it's really needed to do this...so maybe talking silly things here...
    ReplyDelete
  4. booboo: if you go with possibility 2, please leave me a message or post something about it as I'm very interested in (easily) running code in the OF as a plugin (ChinaChip has pretty much standardized that on several of their players).
    ReplyDelete
  5. @Botha:

    The splash screen has a purpose (besides being cool): gives the user time to press SELECT. It can certainly be removed with the only drawback of forcing the user to have SELECT pressed right from reset.

    @Polossatik

    Assuming that the problem is caused by the LCD pixel clock, it is certainly strange that the original firmware does check if the LCD is already running and does not initialize it if it is. This is just an hypotesis.

    Now that I think about it, I had to reverse engineer the piece of code that does the LCD initialization... and don't remember seeing such a thing. I'll give it another look.

    @mcuelenaere

    You can already build programs and run them in the A320 by using the SDK by Dingoo. Google for it. It's a piece of sh*t in my honest opinion, but you can certainly program using it.
    ReplyDelete

Subscribe to: Post Comments (Atom)