Video module

Hi

Starting a new thread …

Since I now have a display setup I would like to make a video module.
I guess I can use OMAP module or the IMX6 one.

I need.

• Access the VOP address.
• Write the RISCOS framebuffer address to the VOP rgb framebuffer register
• write CFGDONE in the vop.

If the above succeed I should get graphics. ON a basic level it should be enough if the screenmode setup is the same as my hardcoded
mode in HAL.

I guess I get the address from the device structure. But right now I have problems with Device_Init, but that can probably be sorted soon.

Ok update..

I wrote a test code in omapvideo to display a bitmap. I get the logical address for the vop, but no write works, no effect.
I can check with *memory p and all is as the driver left it.
The address logical is the same when HAL and in the module.
I write to it like this: vopaddr[offset]=value

It is some kind of pointer error…

If I use the logical directly, a readback gets 0×0 where it should be 0×88 or 0×75 (initial value).

To experiment I did a new pointer to the logical address… Now the readback is 0×88, but in the end it still is 0×75...???

Code from Device_Init that saves the VOP address into device specific..

LDR a1, VOP_Log
STR a1, [a2, #VideoBoardConfig_VOPLOG]
DebugReg a1,"VOPLOG address: "

The Debug prints the same address as the one I am using to setup the VOP.

In c.cmodule I get the very same address.

I am all confused!

I ignored the error and moved forward. I have disabled most hw related things in the module and made it point out the riscos display buffer to the VOP in do_render.
However I get data abort in this:
OS_ScreenMode, INR, ScreenModeReason_StartDriver, graphicsv_drivernumber

Difficult to find the problem. I have traced it down in the kernel, but can’t find anything bad happening. Don’t know how to add debug, but all HAL calls should be ok and safe.
*EDIT

Never mind it was a problem in my GraphicsV…

So now back to the original question,, why can’t I access (read/write) the hardware?

do_render is used for hardware accelerated rectangle copies & fills – it’s the wrong place for setting the buffer address that’s used by the GPU.

For a video driver to work correctly, most of the GraphicsV reason codes need to be implemented and functional. The kernel is pretty dumb, so half-working GraphicsV endpoints may cause it to do weird or annoying things, making it difficult for you to see what the real problem is with your code (there’s a scary flowchart available which attempts to describe the mode change procedure). So to minimise the number of problems you have to deal with at any one time, I’d recommend doing one (or both) of the following:

1. Write a standalone test program that allocates a block of memory using PCI_RAMAlloc and programs the VOP to use that buffer. The OS won’t be able to use it as screen memory (well, not without some nasty hacks), but it’ll allow you to do some basic functionality tests to make sure you know how to program the hardware correctly.
2. Delete 99% of the code from whatever video driver you’re using, because it won’t be relevant. Start from a clean slate (basic module init/finalisation functions, OS_ScreenMode calls to register as a GraphicsV driver, and a skeleton GraphicsV handler). That way if something goes wrong you’ll know that it’s in the code you’ve written (or something missing that you haven’t yet written), not in some code you borrowed from elsewhere which is unsuitable for your hardware, or is malfunctioning because you’ve ripped out some other system which it was meant to be working with.

Difficult to find the problem. I have traced it down in the kernel, but can’t find anything bad happening. Don’t know how to add debug, but all HAL calls should be ok and safe.

You have a data abort, but can’t find anything bad happening? Surely the data abort itself counts as something bad? :-)

I’d start by enabling the debugger exception dumps. You can have them enabled on boot by changing DumpOptions_Default to a suitable value (e.g. DumpOption_HAL_Annotated). The output can be a bit tricky to read (info here) but it’s a lot better than unwinding stack dumps manually (which is what I used to do in the past).

If you do need to add some debug code to the kernel, there are some DebugTX and DebugReg macros which you can use (see s.Kernel)

Thanks for the long answer!
The standalone program needs to be a module I guess..?
I still don’t get why my attempts to write/read to hw fails. It works both ways with *memory/a.

Making it a module isn’t required, but it will make things easier. Memory mapped by PCI_RAMAlloc, and peripheral hardware registers, are inaccessible from user mode. So if your test code was a C app or a BASIC program you’d have to jump through some hoops in order to interact with the hardware.

Ok. I can’t see how I could start a program that is not a module.. The thing I did now was to hijack OMAPVideo and used its init function, just returning after my writes.

I have a early not public version of a video module that is VERY simple and should do for starter. I wonder the term: vdu_init is that the framebuffer?

vdu_init will be the physical address of the buffer that the OS is writing to – which might not be the same as the address of the buffer that’s being displayed on the screen. For the buffer which is displayed on the screen, you’ll want DAG 0.

https://www.riscosopen.org/wiki/documentation/show/GraphicsV%206

Also note that the kernel doesn’t tell you the logical address of any of the buffers (since the kernel likes to manage the logical mapping of the screen memory itself, and ordinary drivers only need to know the physical address)

Small step ahead.. I managed to write to the registers and I INBIN’d a bitmap. However it seems like the memory is void where the bitmap is, I get a black screen (still sync etc).

Hmm according to *memory there is a bitmap in the memory that the rgbframebuffer register points to..

HAH! Not sure why it is tiling it , should be a 1024×768 image.. :)

http://www.update.uu.se/~micken/roolimg.jpg

It was a bad bitmap… Now it is better!
http://www.update.uu.se/~micken/rolcog.jpg

Winner!

http://www.update.uu.se/~micken/video_ro.jpg

GUI: Updated , now with colors!
http://www.update.uu.se/~micken/rodesk.jpg

Shouldn’t the stop sign not be red?

Shouldn’t the stop sign not be red?

Yes. I thought the riscos wanted bgr so I configured that in the VOP. I will switch back.

Better? But the alpha channel is wrong again. What is the preferred mode?

It’s best to ignore the alpha channel if possible – there are still some quirks with alpha modes which means that things don’t work quite right.

Traditionally the OS expects the red channel to be in the low bits of the pixel. But as long as the driver advertises the right pixel formats as being available the OS will also work if the blue channel is in the low bits.

The main gotcha is probably that a “32bit ABGR” mode actually uses pixels of the form 0xAABBGGRR, which might be backwards to how other systems/OS’s describe pixel formats. These are good docs to read:

https://www.riscosopen.org/wiki/documentation/show/Extended%20Framebuffer%20Format%20Specification
https://www.riscosopen.org/wiki/documentation/show/Valid%20Mode%20Variable%20Combinations

Palette/gamma table entries are a bit different, the OS expects the driver to convert them to whatever the correct internal format is.

https://www.riscosopen.org/wiki/documentation/show/GraphicsV%20palette%20colours

Ok will look in to the docs. As you might have noticed I first put it in ABGR mode, then the colors
where wrong (R/B) but the rest looked great. I then swapped back and white lines started to appear ,
just like if alpha bits were ignored (treated like color bits).

Updated thread, more NetSurf friendly. (no embedded images)

Jeffrey, In Video startup it enables vsync interrupt. In my current project it enables a ppi interrupt, which might cause problems. I don’t remember where it takes the number from. Where is it?
Never mind was in my own code :)

In this case I have a framebuffer setup in ram at a specific address. First I tried to map it in in Boot. Now I am doing it in the video module with OS Mem 13.
All I get is some pixels. If I boot up to error I get a longer pixel line.

The fb is the same format as RK port.