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:
- 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.
- 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.
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