RK3288 initial rants

I will get a tinker board this week and I have some questions related to video system:

I have studied the OMAP video module and HAL.
From what I can see the base is a dma copy. Where is DMA setup for the videohardware?
Framebuffer. Related to DMA (SDMA) , I guess it needs a framebuffer. I have tried hard to find where it gets the pointer to the framebuffer, but honestly I cannot find it.
Does the DMA copy output directly to hardware? That would explain some of the performance problems when dragging windows etc. A alternative is discussed below.
Is the screen rendering done because of a change (something is drawn) or is it timerbased , updated in whatever refreshrate the screenmode has?

On the RK3288 side of things..

I have a basic idea on how to use the VOP to get a framebuffer for hdmi display.
It is also possible to use IEP for some doublebuffering, Configure IEP and VOP for direct path. The idea is that RISC OS renders to the source buffer and when do_render is started CONFIG_DONE is written to VOP.
When CONFIG_DONE is issued the hardware takes care on getting the pixels out onto screen.

hi Michael i have just received a nice firefly rk3399 demo unit if you need any testing done let me know, it works well with linux and android it being tested as a interactive display board i will grab it when they have finished with it. i will check to see if they got a usb to uart connector, i downloaded the docs last night will have a read to see how good they are i think it would be a great for a Risc Os port if it can be done. you can get me at rob@interactivedisplays.com.au

hi Michael i have just received a nice firefly rk3399 demo unit if you need any testing done let me know, it works well with linux and android it being tested as a interactive display board i will grab it when they have finished with it. i will check to see if they got a usb to uart connector, i downloaded the docs last night will have a read to see how good they are i think it would be a great for a Risc Os port if it can be done. you can get me at rob@interactivedisplays.com.au

OK the 3399 is a different soc. I don’t know how much they share.

I will get a tinker board this week and I have some questions related to video system:

You’ve got the wrong end of the stick a bit.

• The kernel tells the video driver where the framebuffer is (GraphicsV 6 with R0=0)
• The video driver programs that address into the GPU
• The GPU constantly reads from the framebuffer and sends the pixels to the monitor (i.e. it will do this in real-time to match the timings of the video signal)

The OS will memory-map the framebuffer, so when a RISC OS program renders something it usually does it by writing directly to the framebuffer. The GPU will then send those pixels to the monitor whenever its DMA reaches that area of memory.

The SDMA in the OMAP video driver is used for accelerating rectangle copies and fills (GraphicsV 13). The OS tells it the source/dest coordinates and the driver works out the correct memory region, based around addresses that were previously supplied by GraphicsV 6 (the “VDU buffer” address). RISC OS does support multiple display buffers, but it’s under application control (games will typically use it but the desktop won’t). The relevance to GraphicsV 13 is that the rectangle copy/fill ops need to target the buffer which the game/app is rendering to (GraphicsV 6, 3), rather than the buffer which is currently being displayed (GraphicsV 6, 0).

For systems where the GPU has dedicated VRAM there are two options available.

• The HAL can flag the memory as VRAM when it calls OS_AddRAM to register it with the OS. This is useful for machines where the VRAM is fast enough to also be usable as regular RAM by the OS (e.g. RiscPC)
• The video driver can tell the OS where the VRAM is via GraphicsV 9. This is used on the Iyonix (PCI graphics cards) and Raspberry Pi (the GPU controls the framebuffer location). Ultimately the OS still decides where the framebuffer will be within that area, which isn’t ideal (there have been a number of issues on the Pi relating to this). One of the things on my todo list is to give the drivers more direct control over their memory

If you’re dealing with a system with a unified memory architecture (i.e. pretty much any SoC) then it’s usually best to just let the OS decide where to put the framebuffer (current behaviour is for it to place it at the start of the first block of RAM supplied to OS_AddRAM)

You’ve got the wrong end of the stick a bit.
The kernel tells the video driver where the framebuffer is (GraphicsV 6 with R0=0)
The video driver programs that address into the GPU
The GPU constantly reads from the framebuffer and sends the pixels to the monitor (i.e. it will do this in real-time to match the timings of the video signal)

Thats sound good for me. Where does it the second step in the sources. Can’t really tell.
With this information I will probably implement it using only the VOP as it “reads” from its “framebuffer”.

But, I am still considering if some double buffering would be useful. If I am reading you right there is the possibility that the “GPU” reads from framebuffer at the same time as the kernel writes to it.
Would the system gain from some “snapshoting” of the framebuffer? I mean, if I implement a way to have the image coprocessor to grab the frambuffer in the display rate..

About SDMA. I will most likely do something similar, but I think my first step will be plain software.

Just for your information. the RK3288 works very similar to the i.MX series. Even though there are some differences.
The SOC separates the display process from the GPU, ie in riscos it won’t use the GPU at all.

Thats sound good for me. Where does it the second step in the sources. Can’t really tell.

The OMAP display controller operates almost entirely using an overlay system, so there are a few steps the driver needs to go through.

1. do_setdmaaddress stashes the address in the overlaycfgs array, and calls dispc_update_overay.
2. dispc_update_overlay then calls dispc_get_lloverlaycfg to convert the overlay parameters into a form that’s closer to what the hardware needs; it converts coordinates to addresses and crops it so that it doesn’t exceed the boundaries of the screen (e.g. the mouse pointer overlay may overlap the edge of the screen, but the OMAP display controller won’t like that).
3. Then it calls one of the function pointers in the overlayattrs array to enable/disable the overlay depending on its visibility. On OMAP the different overlays have different capabilities and have different programming methods, so for OMAP3 it will end up calling omap3_gfx_enable or omap3_vid_enable

But, I am still considering if some double buffering would be useful. If I am reading you right there is the possibility that the “GPU” reads from framebuffer at the same time as the kernel writes to it.
Would the system gain from some “snapshoting” of the framebuffer? I mean, if I implement a way to have the image coprocessor to grab the frambuffer in the display rate..

I guess it depends on how bothered people are by flickering redraw issues! Personally it doesn’t bother me much, every OS I use seems to suffer from redraw issues of some kind.

If you want more responsive and less flickery window drag/resize operations then one easy fix is to go into the window settings in Configure and disable the solid drag/resize options. Party like it’s 1990 :-)

If you do want to try adding a double-buffering system, one approach might be to hook onto the Wimp redraw messages (via the filter manager) so that you can work out what areas of the screen are changing. But when I implemented this for the VNC server I found that it didn’t cover all types of redraw operation – IIRC text cursor flashing and DragASprite (e.g. drag & drop of file/folder icons). So some more work to the OS will be needed in order to allow those to be tracked.

About SDMA. I will most likely do something similar, but I think my first step will be plain software.

That should be fine. If you leave GraphicsV 13 unimplemented then the OS will automatically fall back to doing the rectangle copy/fill operations in software.

I see. Thanks. I think I have a basic idea now how to get it running , assuming the regs are physical regs.

Oh crap! Just noticed that USB controller isn’t documented at all!

Asking on the rockxhip-linux channel now to see if someone can throw a doc on me…

USB controller isn’t documented at all

While playing with serial terminals, it looked to me that keyboard and mouse codes could be received from another RISC OS machine this way. I dont know if it has been done already, maybe there has been no need to? I found a recent ps2/serial source that uses it own simple libraries rather than linux ones, this would allow using a RiscPC keyboard, I guess the serial mouse driver (used to be a bit clunky) would work also. I think the tinkerboard has extra serial ports or was it just more serial control? Just a thought, it would let you off the hook from USB stuff for a while.
I noticed tinkerboard on amazon for approx $66 US with international postage.

IIRC when Adrian was porting RISC OS to the Raspberry Pi, he used a laptop to send keyboard and mouse input to the Pi’s serial port. USB support came along quite late.

Yes, there’s the SerKeyMouse module in CVS which provided support for that. There’s also source code there for a Windows app which acted as the other end of the system.

Just a quick question.. From which memory offset does riscos start? I am trying to execute from 0 but it just resets the board, ofcource could be anything, but it seems like HAL isn’t in start..

Off the top of my head while awaiting some pasta cooking, it should start at &0 which will install dummy handlers while setting up the system, putting things in place, and then enabling the MMU at which point everything could change…
One of the HAL sources ought to be the initialisation.

Yes found it now, I simply looked at the binary. I still have remains of the selectconfig stuff from OMAP3. But anyway seems like it is the debug code that resets the board.

There’s no fixed address in physical space. I think the only requirement is that the ROM image must be at least 4K aligned so that it can be mapped in correctly when the MMU is enabled (preferably 1MB aligned to allow the memory to be section-mapped). The OS won’t relocate itself, it’s the responsibility of the HAL or the bootloader to make sure the ROM image is at a sensible location.

If you’re using u-boot as the bootloader then you should be able to tell it where to load the image. But you’d have to check the RK3288 memory map to work out where the RAM is. But you’ve also got to be careful not to overwrite u-boot itself. Usually it’s best to just look at how linux does it (e.g. the load address of the kernel uImage) and then use those same values for loading any RISC OS ROMs.

!Builder can build uImage files directly if you specify the “%subformat”, “%load_addr” and “%exec_addr” parameters in the components file: https://www.riscosopen.org/viewer/view/castle/RiscOS/BuildSys/Components/ROOL/OMAP5?rev=1.3#l4

Off the top of my head while awaiting some pasta cooking

I’m sure there’s a franglais joke about not Pen possible in there…

Just found out why debug didn’t work. RK3288 uart registers doesn’t like byte access , so STRB is no go. Took me a while to figure that out.
So , I am happy printing!

I am up to OS_AddRAM .. or rather it crash right before the call. Checking that now. Bad stack , just guessing,,

Hmmm I am relocating like on OMAP. I wonder if the kernel ends up in void hence the crash.

But it continues to work after relocation and memclear, so at least the HAL is still alive.

How does this work? It jumps to OS_AddRAM, but that address is probably based on the old address. How is that translated?

hi Michael have you got a copy of U-boot that works on RK3399 i can’t seem to find one??

How does this work? It jumps to OS_AddRAM, but that address is probably based on the old address. How is that translated?

Assuming you’re following the same logic as the OMAP HALs:

• The pointer to the OS entry table is calculated prior to the ROM relocation, e.g. in v8 here
• The ROM relocation code will offset v8 by the appropriate amount, e.g. here
• All the entries in the OS entry table are stored as address offsets, so as long as the table address is correct the macro to call the entries should just work.

Of course, since the HAL expects the OS image to be at a fixed location relative to the HAL, there’s no reason why the HAL can’t just recompute the table address from scratch once it’s jumped to the relocated copy of the HAL/ROM.

The CPU in the RK3288 will almost certainly implement the security extensions, so if you’re having trouble with crashes pre-MMU you should be able to program the CP15 VBAR (vector base address register) to point to a table of processor vectors which will produce a register dump (or at least spit out R14) if an exception occurs. Note you may also have to fiddle with the SCTLR to make sure the VBAR is used (IIRC it ignores the VBAR if high processor vectors are enabled)

Ok. I might try the last suggestion. The call to InitARM goes ok, so I that stage kernel space is working.

I have tried to skip relocation and made sure that RAM for riscos starts above the osimage. But the call to AddRAM still crashes. It is the jump in itself that crash, that is if DebugTX and friends works from AddRAM.

A observation that suggests that a atempt to relocate fails is that DebugReg isn’t working (works without relocation) it just prints 0000000.

if DebugTX and friends works from AddRAM

They do not. The debug macros the kernel uses only start to work halfway through OS_Start, once the MMU has been enabled and HAL_Init has returned.

If you want to add debug to the kernel prior to the MMU being enabled then you’ll have to use your own code/macros (e.g. just hardcode the physical address of the UART)

If you want to add debug to the kernel prior to the MMU being enabled then you’ll have to use your own code/macros (e.g. just hardcode the physical address of the UART)

OK, will do that. I just tried VBAR. The routine I pointed to (left everyting point to one routine) didn’t stop the board from reseting. Needless to say I configured SCTLR.

Ok so new status:
I am getting as far as entering MMU activation zone.
It is tough for me to know whats happens between that and HAL_Init where I mapin the UART and can start printing again.

I notice that there are some hardcoded assumptions..
Is the ROM location in the ASSERT ROM xx refer to physical space or logical. ?

Anyway this is fun!

Happy day! I am past MMU activion and am now in HAL_Init.
I did a hack , just using the logical address and put out a character. Now on, why doesn’t the UART hal routines work…

Is the ROM location in the ASSERT ROM xx refer to physical space or logical. ?

Logical.

With the current memory map, the HAL+ROM will start at &FC000000.

Happy day! I am past MMU activion and am now in HAL_Init.

Congratulations!