Orange Pi One: HDMI output -> force HDMI output resolution 800x480 and boot from (external) SPI Flash

[vanvught]

Request by email from @Vampir8

The resolution is set n U-Boot and that does not work -> http://u-boot.10912.n7.nabble.com/SUNXI-CONFIG-VIDEO-SUNXI-is-never-set-td360711.html

I would need to check with the latest U-Boot version. Or otherwise, translate this code https://github.com/u-boot/u-boot/tree/master/drivers/video/sunxi into baremetal code.

[vanvught]

http://u-boot.10912.n7.nabble.com/SUNXI-DE2-H3-Add-support-for-setenv-video-mode-td395068.html

cc: @Vampir8

[vanvught]

I am going to port the U-Boot files:

sunxi_de2.c 
sunxi_dw_hdmi.c 
lcdc.c 
../dw_hdmi.c

cc: @hippyau

[hippyau]

Hey Arjan!

I am coming to appreciate why a fixed resolution would be good, every monitor is giving different sizes :)

I am wondering if the register where fb_addr comes from can be changed at runtime, to another block of memory and back again, to make double buffering possible? like display flipping, where we can write off screen, and then change the register to point to the new frame?

I am drawing really quickly with a font I've embedded, for a timecode display.
i can render the font in less than a millisecond, it looks really cool, but I get a lot of flicker.

I looked up the data sheet, but there was not enough information about how it works, where do we find more detailed info on this register? Maybe I should just try allocating a block of memory the size of the FB and try it?

Also wondering :) if you are looking at porting the HDMI code from u-boot, I wonder if the TV/CVBS encoder code might come along too, for the oPi Zero? I believe they they share much in common?

Cheers, Hip

[hippyau]

Actually, maybe a VSYNC interrupt or signal would solve the flicker, do you happen to know if there is one?

I've slowed down to just draw every 33ms and the flicker is better, but it's still there. :)

[vanvught]

Hi Hip,

double buffering possible?

Yes, the framebuffer address is set in this register -> https://github.com/vanvught/rpidmx512/blob/experimental/scratch-h3-hdmi/lib/h3_de2.c#L149 So we can define several regions in the upper memory (which I need to check if it is set to uncached in the MMU). Then we can create a h3_fb_swap function , change the address register and do an apply for the new setting -> https://github.com/vanvught/rpidmx512/blob/experimental/scratch-h3-hdmi/lib/h3_de2.c#L152

[vanvught]

which I need to check if it is set to uncached in the MMU

That is looking good ;-)

https://github.com/vanvught/rpidmx512/blob/9c45c8d49098310b43ca03a5712f2c3c3ed49953/lib-h3/arm/mmu.c#L139

Currently there is 32MB (https://github.com/vanvught/rpidmx512/blob/fe4f87c296dbd70434fe969fad66f788d219df69/lib-h3/include/h3.h#L40) uncached frame buffer region.

[hippyau]

Awesome!!!!! :)

I'll get up to speed with your code tomorrow, but really should sleep now :)

I'm written a very lame window drawing class, and working with this really efficient font embedder to render ttf fonts. It's pretty ugly at the moment with the window stuff, but it has callbacks to render the window content on demand, but no overall window.run() or anything yet.

This is just testing stuff, nothing special...

Cheers :)

[vanvught]

This is just testing stuff, nothing special...

Looking really cool already!

At the end of the day we can create a hdmi.txt file where we specify the monitor configuration. That is much easier than implementing (porting) the EDID read function.

I am testing/debugging the sACN E1.31, Art-Net and OSC real-time monitor's. As we now can boot from SPI flash, the remote configuration framework can be enabled as well.

[hippyau]

Cheers :) wait until you see the code though, bahahaha!!

I just looked at your HDMI code, while super impressed I and am pretty sure I will have scary dreams tonight because of it :)